SMS per minute | Search |
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through June 02, 2006 ⬆ |
◄ ► |
Author | Message | |||
Pablo Pietropinto New member Username: Ppietro Post Number: 1 Registered: 02-2006 |
How many sms per minute is possible to receive via SMPP?? Best Regards Pablo Pietropinto | |||
vas New member Username: Vasnet Post Number: 1 Registered: 02-2006 |
Hi, Please Send the Sms through asp.net coding | |||
vas New member Username: Vasnet Post Number: 2 Registered: 02-2006 |
50 Messages | |||
Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5589 Registered: 10-2002 |
There is no set answer to this. It depends on your service provider. If you are using the 2-way SMS facility in NowSMS with HTTP callbacks, then in a default configuration, NowSMS can only process 3 to 4 HTTP callbacks per second. (Less if your script performs considerable processing.) There is a configuration parameter to allow NowSMS to allocate more threads to the HTTP callbacks so that you can process the messages more quickly. (Just make sure that your HTTP callback is ok with multiple simultaneous requests.) Here is the documentation for the setting that I'm referring to in the [SMSGW] section of SMSGW.INI: 2WaySMSThreadCount=## When NowSMS receives an SMS message over an SMSC connection, it can be configured to process a "2-way" command to process the message. NowSMS queues the received SMS message, and a separate thread within NowSMS processes the callbacks, so other gateway activity of sending and receiving messages can continue while the callbacks are being processed. This approach is reasonably efficient. However, if you receive a large volume of messages, our experience has shown that HTTP callbacks can only be processed at a rate of 3 to 4 messages per second. If you need to process inbound messages at a faster rate, it is possible to allocate additional threads to the receive SMS processing. This parameter specifies how many threads should be allocated for processing received messages. In practice, the overhead of allocating additional threads for this processing is relatively low, as the threads spend most of their time waiting for a message to process or waiting for an HTTP response from the callback that is issued. |