| Accounting callback another question |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through December 14, 2010 ⬆ |
◄ ► |
| Author | Message | |||
| Alexandre Frequent Contributor Username: Alexd Post Number: 114 Registered: 01-2008 |
Hello! How many HTTP inquiries in a second can process NowSMS? Whether there are any tests on this question? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2444 Registered: 08-2008 |
We test primarily with dummy callbacks where we request a static text file from the server rather than calling a script. The reason for this is because we need to analyze the amount of overhead that is involved in our end of processing the request. There is overhead, but it generally averages a couple of milliseconds. When implementing callbacks, it is a good idea to analyze the SMSDEBUG.LOG to see the timestamps of how fast your callback is processed. The more significant delays tend to be on the script end. NowSMS uses multithreaded logic to attempt to minimize the effect of the callbacks. For example, when sending outbound messages, the SMSOUT accounting callbacks are processed in a separate thread from the protocol logic to minimize the impact on outbound message sending speed. However, where you can see more performance impact is on message submission. NowSMS will not accept a message until after the pre-auth callback, and that client connection is blocked while waiting. The SmsSend callback is also processed before the next message is accepted from the client. If you have multiple clients, it is insignificant. If you have a single client submitting at maximum speed, they will be slowed down. Analyzing timestamps in the SMSDEBUG.LOG while developing the callbacks is a good idea. Also keep in mind that multiple callbacks can be occurring simultaneously, so try to avoid blocking transactions. | |||
| Alexandre Frequent Contributor Username: Alexd Post Number: 116 Registered: 01-2008 |
I meant a bit another, how many HTTP requests per second can accept NowSMS ? We want send 100 000 messages in best time. Our steps: 1. Split 100 000 messages in 10 000 2. Start 10 threads and send in everyone http request 250 mobile numbers. And we have seen that periodically arise Web Exception Timeout. What optimum quantity of inquiries can accept NowSMS? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2453 Registered: 08-2008 |
"Web Exception Timeout" ... I need clarification what you mean by this. I assume that you are saying that the HTTP client submitting the message receives a timeout. This can be a problem with web submissions to a large number of recipients if you are using the SMSAccountingPreAuthPerRecip=Yes setting, which you might be using to enable support for "RouteCharge". This setting means that NowSMS has to perform an HTTP PreAuth accounting callback for each recipient of a bulk messaging submission. (Without this setting, the PreAuth callback asks for permission to send to "x" recipients.) If the bulk submission is coming in via SMPP, they're already coming in one at a time. But, if you're performing bulk submission to a large distribution list via HTTP, it will take some time to process all of the PreAuth accounting callbacks. Let's say you're submitting to 100,000 recipients, and the callback takes 50 microseconds. This means it will take 500,000 microseconds to process the callbacks before an HTTP response can be returned to the submitter. 500,000 microseconds = 500 seconds = 8 minutes and 20 seconds. (A typical HTTP client timeout is 2 minutes, but it varies based upon client implementation.) Hopefully your callback takes less than 50 microseconds. Having more submit threads and smaller submit batches should improve performance, as long as your accounting callbacks do not include a lot of blocking logic which would cause them to slow down further if multiple accounting callbacks occur simultaneously. If you have more submit threads with smaller groups of numbers, and the callbacks do not have a lot of blocking logic, you should see performance improvement by doing things this way. All that said, I'm making an assumption based upon recollection of past discussions that suggests you are using the SMSAccountingPreAuthPerRecip=Yes setting. | |||
