Shanjay, I agree with Nikos, the normal scenarios are in the 20-40SMS/sec.
I had carriers that in the agreements requested us to handle 400SMS/sec (its crazy) and in fact we have received sometimes peaks of 290SMS/sec. The issue is if the carrier can handle your replies at the same speed as, if they send 400SMS/sec but they limit you to 40SMS/sec you may have a big business loss due to the time to send the reply to the user. The biggest sustained traffic originated by TV promotions we had was around 150SMS/sec per bind, and after small carrier interruptions we have received peaks of up to 290SMS/sec. You cant figure out how much adrenaline runs in that moments! Let me suggest you to take special care of: - Network connections: The quality of the connection is essential, minimum network outages cause SMPP interruptions that are hard to handle with heavy traffic. - Redundancy: As any minor interruption (or worst a system crash) with that levels of traffic could be mortal. Having redundant binds & servers is a must!!! - Whole system configuration: The whole system (gateways+application servers+database servers) must have capacity to handle that huge traffic levels, not just the kannel gateway. There are many many variables to have in mind depending on your http server, operating system, language (php, java, even 'C'). Besides all of them I suggest to have a fast buffer mechanism at the application layer where kannel inserts the MOs and a process send the MTs to Kannel (i.e. local incoming queue / local outgoing queue). Regarding the computers for gateways, we use Linux and we have disabled all non essential services, the best results we had for the kannel queues was using solid state disks but I agree that there are filesystems that are fast enough with a reasonable risk and less CAPEX. As a 400SMS/sec per bind capable system is so expensive to design, make, implement and operate, before any movement let me suggest: please double check with other industry partners to know wich is the real case scenario, if they have received 400SMS/sec sustained traffic in your country. It is very possible that they are in the normal 30-40SMS/sec... If you need anything else, let me know. Best Regards, Daniel. [email protected] -----Mensaje original----- De: Nikos Balkanas [mailto:[email protected]] Enviado el: miércoles, 25 de agosto de 2010 02:29 a.m. Para: Sanjay Bhandari CC: [email protected] Asunto: Re: Kannel throughput against a real SMSC Normally the throughput numbers I configure with real SMScs are in the range 20-30 SMS/s. 400 sounds too much. BR, Nikos ----- Original Message ----- From: "Sanjay Bhandari" <[email protected]> Cc: <[email protected]> Sent: Wednesday, August 25, 2010 6:03 AM Subject: Re: Kannel throughput against a real SMSC > They are telling is the cap is per bind, so that would be per > connection (client). > > And yes, we are going to look into network issues. What kind of numbers > have you seen (working against a real SMSC)? > > On 8/24/2010 11:00 PM, sangprabv wrote: >> 400SMS/sec for each connection (client) or for all connections (clients)? >> Network issue might be also need to be checked. >> >> >> >> sangprabv >> [email protected] >> http://www.petitiononline.com/froyo/ >> >> >> On Aug 25, 2010, at 9:32 AM, Sanjay Bhandari wrote: >> >>> Anyone here have experience working against a real commercial SMSC? >>> >>> We got decent numbers working against fakesmsc (~1700 SMS/sec >>> sustained), but get really atrocious throughput against a real SMSC (~30 >>> SMS/sec sustained). The provider is telling us that they cap the rate at >>> 400 SMS/sec per bind. But we are not even close. Next step is for us to >>> dig into the Kannel-SMSC interface and see what's going on. >>> >>> I wanted to reach out to folks who have done this before, to ask what >>> the typical experience was, just so we can focus on the right areas in >>> trying to debug the issue(s). Thanks for any input. >>> >> >
