| SMS Client sending to many SMS to NowSMS ....... |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through July 28, 2014 ⬆ |
◄ ► |
| Author | Message | |||
| Nelson Lam New member Username: Nelsonlam Post Number: 16 Registered: 02-2013 |
Dear Tech Support - Currently we are using NowSMS v2013.09.26 license at 3sms per second - our NowSMS is connected to smpp client "cl-1" (inbound)and SMSC provider "smsc-a" (outbound) with all inbound SMS route to outbound using SMSSend accounting call-back to route the SMS to smsc-a The situation is like this: - cl-1 (example: vodafone) sending SMS which may burst upto 20 SMS in 1 sec. - cl-1 found that a lot of submit_sm did not acknowledged by submit_sm_resp-ok from NowSMS or some of the submit_sm_resp returned after 2 minutes. - this cause cl-1 submit_sm timeout (their timeout set to 20 sec) - cl-1 requires to reply submit_sm_resp-ok back to their upstream in realtime mannor. This in turns causes their upstream also timoeout the SMS as well and upstream will resend SMS again. We would like to know: - can NowSMS trigger submit_sm_resp-ok immediately upon receiving submit_sm? - can NowSMS server send back Throttling error back to cl-1 in this case ? (we try to set "Limit Speed of receiving messages for this account" to 3 but we didnot see NowSMS sending Throttling Error to cl-1 when it is sending more than 3 sms per sec to NowSMS). Your help is very much apprecited. Thanks. Best Regards Nelson | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4755 Registered: 08-2008 |
Hi Nelson,
If you do not set a receiving speed limit on the client account, NowSMS will always send the submit_sm_resp immediately. The NowSMS license limit does not restrict NowSMS from accepting messages, only submitting them upstream. If you set a receiving speed limit on an account, this does slow down NowSMS sending submit_sm_resp, with NowSMS sending submit_sm_resp back at that rate. If you do not set "Limit Speed of receiving messages for this account" ... NowSMS will not delay submit_sm_resp. If you have not set this limit and you are seeing this behavior, then my best guess would be that something is going wrong with the callback processing, and that these issues are triggering the delays. In particular, the PreAuth callback must complete before the submit_sm_resp is sent back. The first thing I'd suggest doing is adding AccountingKeepAlive=No under the [SMSGW] header of SMSGW.INI. This disables the use of HTTP Keep-Alive sockets for accounting callbacks ... instead NowSMS makes a new HTTP connection for each accounting callback. Assuming the web server hosting the callback is on the same local network, there is no real performance drawback to disabling this setting. Some web servers have Keep-Alive problems, and this could trigger the type of delay you are seeing. Next, enable the SMSDEBUG.LOG, and see if you can follow the callback timing to see if there are random delays or consistent delays. If you need help, e-mail that SMSDEBUG.LOG to nowsms@nowsms.com with Attention: Des in the subject line, and I will look at it to tell you what I see. I have seen random problems like this fixed by adding AccountingKeepAlive=No, so please give that a try first. Also keep in mind that NowSMS may be processing multiple accounting callbacks simultaneously, so you need to make sure your accounting callbacks are able to handle this. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4760 Registered: 08-2008 |
Hi Nelson, Thanks for the log files. I'm replying here because I think this information may be helpful to others. The configuration setting I mentioned is irrelevant. The accounting callbacks are simply taking too long to process. You need to optimize the logic in your accounting callbacks to improve performance. The PreAuth callback performance, in particular, must be sped up. From looking at your logs, it takes at least 450ms (almost 1/2 second) to get a response to the PreAuth callback. This particular callback is asking if the message should be accepted (and can be used to specify how the message should be routed). submit_sm_resp will not be returned until a response is received for this callback. For a single connection, these callbacks are processed serially, with a logic flow something like this: submit_sm received Callback: Type=SMSSend&PreAuth=Yes submit_sm_resp sent Callback: Type=SMSSend Check for next submit_sm to process So the callbacks have a direct impact on how quickly messages are processed on a single connection. Similarly, Type=SMSOut callbacks will impact how quickly messages are sent out to an SMSC connection. For multiple connections, NowSMS may be processing (and waiting on) multiple callbacks on different connections. It is also important to consider this. If your callbacks perform some sort of file or database locking, they may become even slower when multiple callbacks are processed at the same time. To get an idea of how long each callback is taking to process, you can look at the SMSDEBUG.LOG. Look for a RetrieveURL entry that has a NowSMS User-Agent string on the next line. This is when NowSMS sends the accounting callback request. Then look for an HttpResponseWait response with a matching number and compute the time difference. 16:42:24:446 [6] RetrieveURL: GET /<omitted> HTTP/1.1 User-Agent: Now SMS/MMS Gateway v2013.09.26 Accept: */* Host: 127.0.0.1 16:42:25:431 [6] HttpResponseWait: Ok 16:42:25:431 [6] RetrieveURL: HTTP/1.1 200 OK For example, the above request took 985ms for a response (16:42:25:431 - 16:42:24:446), or almost a complete second. In this case, NowSMS was issuing multiple callbacks at the same time and it seemed to cause the callback to take even longer to process, because most of your callbacks seem to take between 450ms and 500ms. The callbacks need to be quicker in order to keep up with the message flow. -- Des NowSMS Support | |||
| Nelson Lam New member Username: Nelsonlam Post Number: 17 Registered: 02-2013 |
Thanks Des, you are really amazing !! Your information definitely help us in solving the problem. After modifying our program logic, the submit_sm_resp really speed up and the performance ramp up. We are now looking at the other application of NowSMS. We would like to connect NowSMS as follows: Op1SMSC | (smpp) | NowSMS-a(Buffering)---(smpp)-->NowSMS-b--->Op2SMSC | +---------------------(smpp)-->NowSMS-c--->Op3SMSC Op1SMSC - Mobile Operater 1 SMSC Op2SMSC - Mobile Operater 2 SMSC Op3SMSC - Mobile Operater 3 SMSC -Op1SMSC sending high speed SMS data (i.e. over 10 sms per sec) to NowSMS-a (acts as buffering) -NowSMS-a configured to use prefix routing under NowSMS's SMSC configuration (NOT deploying Callbacks) which load sharing the inbound traffic to NowSMS-b and NowSMS-c -NowSMS-b and NowSMS-c will be setup to use Callbacks which runs at most 3sms/sec. The Callback will perform billing and authentication. Questions: -For this type of connection, can we implement NowSMS-a to buffer the high speed sms send form Op1SMSC and send out at a low speed via NowSMS-b and NowSMS-c? -Can you explain more on the logic how NowSMS-a will send out submit_sm_resp to each submit_sm enter it, if we just use prefix routing instead of callbacks? -For the single connection that Op1SMSC connects to NowSMS-a, how fast can NowSMS-a response to the submit_sm ? Will NowSMS-a handles submit_sm serially and how fast could it be(only prefix routing will be deployed in NowSMS-a, NO more callback use on it)? Thanks. Best Regards Nelson | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4761 Registered: 08-2008 |
Hi Nelson, Sorry for the delay in response. To answer your questions in order ... Yes. In that scenario, NowSMS-a would send back the submit_sm_resp as fast as possible. The only action taken before sending back submit_sm_resp would be to save the message data to disk, which is practically instantaneous. Exact speeds depend on the disk performance, but generally we're talking fractions of 1 ms up to 5ms. Messages received are still processed serially, but the processing time is minimal. So we're talking about being able to accept 100s per second, not 10. The submit side may still be using async mode, as NowSMS is buffering received messages, it just doesn't send submit_sm_resp for each message until it has successfully saved it to disk. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4762 Registered: 08-2008 |
Hi Nelson, Sorry for the delay in response. To answer your questions in order ... Yes. In that scenario, NowSMS-a would send back the submit_sm_resp as fast as possible. The only action taken before sending back submit_sm_resp would be to save the message data to disk, which is practically instantaneous. Exact speeds depend on the disk performance, but generally we're talking fractions of 1 ms up to 5ms. Messages received are still processed serially, but the processing time is minimal. So we're talking about being able to accept 100s per second, not 10. The submit side may still be using async mode, as NowSMS is buffering received messages, it just doesn't send submit_sm_resp for each message until it has successfully saved it to disk. -- Des NowSMS Support | |||
