I know that the limit is 100 TPS, and our own appliation measure around
85/sec (sometimes lower, sometimes higher), but in this number also the
database actions and business logic is measured.
I think the 100 TPS is for MO and MT. They are going to raise this though.
Also I am thinking to install the sqlbox, I think that could safe a lot
of performance. The http call to sendsms is probably slowing down the
process too.
Nikos Balkanas wrote:
Hi,
85 SMS/s sounds very low to be disk I/O limited. If in doubt bench with
fakesmsc. It doesn't connect over the network, therefore no charges, but
it does all the disk I/O of a real connection. The number you get out of
it is the real number of your system. All other delays are your SMSCs.
100 SMS/s sounds high. Is this all for MT? MT + MOs? I imagine DLRs are
excluded. What does your provider say?
I would raise threashold to 150, watch for threashold exceeded warnings
and measure the throughput again.
BR,
Nikos
----- Original Message ----- From: "Rory Campbell-Lange"
<[email protected]>
To: "Alejandro Guerrieri" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, January 05, 2010 11:03 PM
Subject: Re: SMS per second
On 05/01/10, Alejandro Guerrieri ([email protected]) wrote:
If the store spool builds up, ext3 could become a serious performance
hog.
If disk IO might be the problem the iotop tool is an excellent way of
watching what processes and disk partitions may be causing a problem.
According to the man page, iotop requires Linux kernel 2.6.20 or later.
--
Rory Campbell-Lange
[email protected]
Campbell-Lange Workshop
www.campbell-lange.net
0207 6311 555
3 Tottenham Street London W1T 2AF
Registered in England No. 04551928
