| Important question about SMSAccountingURL |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through September 26, 2009 ⬆ |
◄ ► |
| Author | Message | |||
| Alexandre New member Username: Alexd Post Number: 8 Registered: 01-2008 |
Hello! We create analyzer HTTP Query from Now SMS, have made record in smsgw.ini, have registered parametre SMSAccountingURL=http://127.0.0.1/ProcessSMS.aspx Also have faced a problem that when it is dispatched more than 20000 SMS speed of sending sharply falls and queue is stored and reaches the huge sizes, NowSMS starts to dispatch very slowly messages in SMSC. If we switch off option SMSAccountingURL that all normally. We can send test installer our tools on processing http parametres, it seems to us that NowSMS does not cope with a considerable quantity of inquiries. | |||
| Alexandre New member Username: Alexd Post Number: 10 Registered: 01-2008 |
No any update ?  | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 7798 Registered: 10-2002 |
Hi Alexandre, The version of NowSMS can make a big difference here. When we first implemented keep-alive sockets for accounting callbacks, only one accounting callback could be active at a time. This created a big bottleneck that could really slow things down. I don't recall exactly when this was fixed. But you may see a difference in the most recent download at http://www.nowsms.com/download/nowsms2009rc.zip. Something else that you may want to try is editing SMSGW.INI, and under the [SMSGW] header adding AccountingExtended=No. This disables the "SMSIN" (received messages via an SMSC connection) and "SMSOUT" (when a message is routed out via an SMSC connection) callbacks. At least see if this makes a difference. If the messages are being dispatched very slow, it suggests some sort of slow down related to the "SMSOUT" callbacks, as those are processed in the same thread as outbound message submission to the SMSC. Other thoughts ... make sure async mode is enabled on SMPP connections. If there is some delay on "SMSOUT" accounting callbacks, it will be less of an issue in async mode. It is also possible that there is a keep-alive problem. Try editing SMSGW.INI, and under the [SMSGW] header, add AccountingKeepAlive=No. -bn | |||
| Alexandre New member Username: Alexd Post Number: 14 Registered: 01-2008 |
"I don't recall exactly when this was fixed. But you may see a difference in the most recent download at http://www.nowsms.com/download/nowsms2009rc.zip." - it`s 2009.05.21 version ? Or newest ? | |||
| Alex Kaiser New member Username: Alex_k Post Number: 18 Registered: 07-2006 |
Hello Bryce and Alexandre! We have faced the same problem, sometimes NowSMS is not able to push more than 10-15 sms/sec. When we switched off accounting, outbound speed became normal. I don't know where to dig but seems our HTTP request handler or NowSMS has very serious performance lack. Regards, Alex K.} | |||
| Alex Kaiser New member Username: Alex_k Post Number: 19 Registered: 07-2006 |
i think we can increase outbound speed not only by creating multiple bind like [SMPP] [SMPP#2] [SMPP#3] and etc. If you add special paramater for smpp link: bind with 3 transmitter and 1 receiver. That will add performance. | |||
| Alex Kaiser New member Username: Alex_k Post Number: 20 Registered: 07-2006 |
Another issue, we have matched performance by windows built-in performance counter. Our http handler response page vary 5-10ms but NowSMS speed decreased at least 2 times. :-( 10-30 sms/sec atm. Regards, Alex K. | |||
| Alex Kaiser New member Username: Alex_k Post Number: 21 Registered: 07-2006 |
in addition, we noticed that if queue size exceeds 10-15k - performance fall down, if below that size high sending speed restores. Maybe that could be a clue... Regards, Alex K. | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 7805 Registered: 10-2002 |
That's fine. It's 2008.11 thru 2009.04 versions that are somewhat suspect. I'd be curious if the INI file settings have any impact. I'm struggling to determine what the link is between queue size and accounting callbacks effecting sending speed. Unfortunately, we are short staffed this week, so I may not be able to run any tests to try to duplicate this for several days. I would be very curious about how those INI file parameters affect the situation. In particular, I'm wondering if there is some sort of keep-alive socket issue. -bn P.S. - I like the # binds suggestion. It's been on our list for awhile. We made some internal changes last year to move toward implementing this, but there is still more work to be done. | |||
| Alex Kaiser New member Username: Alex_k Post Number: 22 Registered: 07-2006 |
Hello again, We have tested those parameters: AccountingKeepAlive=No - no performance influnce AccountingExtended=No has an impact but NowSMS doesn't send any request when message has sent or delivered, so it's similar if we just switch off accounting. I will try to describe the situation better: While in the q 5-7k messages everything is going fine. We queue has reached 15k, sending speed begins to float. 7 sec - NowSMS sends 100sms/sec, another 5 sec - 20-40 sms/sec after that speed decreasing to 2-3 sms/sec. After that NowSMS freezes(0sms/sec) for 5 sec and then return to normal speed 100sms/sec. I think that situation is a little bit similar to that bug with q size, when NowSMS restarting rapidly if queue size exceed 50k. Looking forward for your promt response. Also here is sample of ini file: [SMSGW] AccountingKeepAlive=Yes ReceiveSMS=No ReceiveMMS=No ReceiveSMSCharset=utf-8 WebAuth=Yes WebMenu=Yes WebPort=8800 WebPortSSL=9900 SMPPPort=2775 SMPPPortSSL=3550 SMPPThrottleErrorDelay=10 TrackSMPPReceipts=Yes CacheQSize=Yes SeparateUserQueues=Yes UserQueueThreshold=10 QDir=D:\NowSMS.Queue BulkQDir=D:\NowSMS.BulkQueue LogDirectory=D:\NowSMS.Logs UsersDir=D:\NowSMS.Users SMSInDir=D:\NowSMS.IN MessageIDTrackingDir=D:\NowSMS.DR DefaultMsgLimitPerDay=999999999 DefaultMsgLimitPerMonth=999999999 SMSAccountingURL=http://192.168.0.20/QueryManager/ProcessSMS.aspx Modem1=SMPP - LINK:2770 Modem2=SMPP - LINK:2780 Modem3=SMPP - LINK:2790 Modem4=SMPP - LINK:2800 Modem5=SMPP - LINK:2810 Modem6=SMPP - LINK:2820 Modem7=SMPP - LINK:2830 Modem8=SMPP - LINK:2840 Modem9=SMPP - LINK:2850 Modem10=SMPP - LINK:2860 Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 954 Registered: 08-2008 |
Hi Alex and/or Alexandre, I've been running some tests on this. Are the messages being submitted into NowSMS using HTTP or SMPP? I haven't noticed anything usual with SMPP yet. However, I have noticed that if messages are submitted via HTTP, the NowSMS "bulkQ" logic is choppy. By default, this logic is triggered if a single message submission is directed to more than 10,000 recipients. What happens is that NowSMS queues the messages in blocks of 10,000. However, it doesn't process any of each 10,000 message batch until it has completed accounting callbacks for all 10,000 recipients. As a result, you can end up with choppy performance as each batch is built and then released. As a test, I'd suggest editing SMSGW.INI and under the [SMSGW] header add EnableBulkQ=No. With the way that NowSMS uses multiple subdirectories for message queues, it is normally not a problem to disable the bulk Q (in fact, we do it routinely when we are doing performance testing). The only problem with using this setting is that the HTTP response back from NowSMS when you submit a large batch of messages will take longer (the difference will be great if accounting callbacks are not used, but not as great if accounting callbacks are used). If you're not submitting large batches of messages via HTTP ... then ignore all of this, and we'll have to keep looking. -- Des NowSMS Support | |||
| Alexandre New member Username: Alexd Post Number: 15 Registered: 01-2008 |
So last patch 2009.06.30 not fix this issue ? P.S. When u reliz final 2009 version of NowSMS ? ;) | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 977 Registered: 08-2008 |
Hi Alexandre, Does my message above accurately describe the situation that you are encountering? (I was not sure if your inbound messages were arriving via HTTP or SMPP.) This issue is too difficult for a "quick fix". (And we hope that 2009.06.30 will be the new formal release of the product.) I think it is more an issue of tuning, not a fix. EnableBulkQ=No may be a solution. Another solution may be to tune the 10,000 recipient block size to a lower number. There is an undocumented setting MaxQDirEntries=##### that can be used to tune this block size. I'd suggest trying 5000 ... maybe 2500 ... -- Des NowSMS Support | |||
| Alexandre New member Username: Alexd Post Number: 16 Registered: 01-2008 |
Ok..thanks..for answer, we will testing | |||
| Alex Kaiser New member Username: Alex_k Post Number: 23 Registered: 07-2006 |
Hello All messages are submitted over HTTP with defined SMSCRoute parameter. NowSMS doesn't send sms as as fast as possible over outbound smpp link, that is the problem. Also we noticed that SMSAccounting haven't any serious influnce on the performance. Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 984 Registered: 08-2008 |
Hi Alex, SMS accounting has a major impact in my testing, so I'm a bit confused by that. The issue that I observed is this ... If you submit a message via HTTP to more than 10,000 users, NowSMS will not start processing any of these messages until 10,000 accounting callbacks have occurred. If you submit a message via HTTP to less than 10,000 users, messages are queued individually, and the accounting callbacks do not cause a bottleneck. Maybe I'm still not understanding something about the problem that you are facing. In my tests, I would submit 100,000 SMS. No outbound messages would be processed until the first 10,000 accounting callbacks occurred. Then those 10,000 messages would be released. Those messages would usually get sent out before the next 10,000 were released. As a result, NowSMS is not saturating the outbound SMPP connection. Maybe there is something else that you are encountering which I am missing. Are you submitting messages via HTTP to many recipients in one submission? -- Des NowSMS Support | |||
| Alex Kaiser New member Username: Alex_k Post Number: 25 Registered: 07-2006 |
Hello, Let me explain how we do handle accounting requests. We recognize: PreAuth – issued before sms haccepted by system SMSSend – issued when sms placed in the queue SMSOut – issued when external system accepted the sms DR – when delivery receipt came Naturally we don’t have any problems with PreAuth and SMSSend requests, we are able to put in the queue as much messages as we need. Problem happen between SMSSend and SMSOut, we have about 8 outbound link 30-50 sms/sec each. Also we know that NowSMS won’t process next message in queue until SMSOut got HTTP 200 response. If you write directly to database updating operations cause huge delays and message queue freezes, that could be a bottleneck. In that scenario, we made an update to our requests handler, atm we are writing all requests to the cache memory instead of database, each operation consume 3-5ms, so there couldn’t be any bottleneck. Am I wrong or missing something? If we submit to the single outbound link outbound speed 15-30 sms/sec but if send over all connections speed rises up 30-50sms/sec and even 100 sms/sec for short period. But of course that is not a peak Our test server: dual Xeon, 32gb RAB, 6xSAS disk 15k RAID5, so I think that is not hardware problem :-) Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 996 Registered: 08-2008 |
Hi Alex, I am a little confused because there have been different people discussing this issue and a possibly related issue across at least two discussion threads. I get confused between the different configurations. I'm also confused, because I thought your problem started off being a performance problem when accounting is enabled. But, no performance problem when the extended callbacks are turned off (meaning no "SMSOUT" callback). So I get confused when you say that the accounting callbacks are not a performance factor. Upping the window size on the SMPP async connections (you do have SMPP async enabled, right) may be a solution. Regarding your discussion about the SMSSend and SMSOut delay, it is a good idea to cache the SMSOut logging. If you are using async mode SMPP, activity will not stop on the connection while we are waiting for the SMSOUT callback to complete. However, it may keep the async window at its max size if the callbacks are too slow, preventing the next message from being added. That's why I suggest a larger window size might be the answer. You might exceed the window size that the provider supports, but chances are that you won't (and that it won't really matter if you do) ... because the provider may have already acknowledged the message, but NowSMS is still clearing the window on its side because it has to process the corresponding accounting callbacks. -- Des NowSMS Support | |||
| Alex Kaiser New member Username: Alex_k Post Number: 26 Registered: 07-2006 |
Hello Des, Thank you for you response. Well, I can tell about only my experience using NowSMS’s callbacks. We have to similar servers: one with enabled callbacks and one with not and we make similar tests. Seems that performance of callbacks enabled is much less. We don’t know how to monitor the problem. Maybe you could make some built-in tools for performance testing and diagnostics? All outbound links are in async mode but changing of window size (50-2000) doesn’t make any performance influence. Regards, Alex K. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1001 Registered: 08-2008 |
Hi Alex, I think I got confused when a few messages up in this thread when you said:
It's also a little confusing because Alexandre has a similar name to you ... but I don't think you two are working together and are talking about separate issues. So, let's regroup and refocus. Here's what I think is true ... 1.) When an SMSAccountingURL is defined, you experience slower outbound SMS message throughput. 2.) AccountingKeepAlive=No was tested, and found to have no effect on performance. 3.) AccountingExtended=No was tested and its effect was similar to turning off accounting completely. If all of the above is true, then it suggests that the problem is related to emptying the queue, not filling it. The SMSSend callbacks do not appear to be causing a performance problem, because they are still being called when AccountingExtended=No, and performance is fine. Based upon this observation, the discussion about disabling the bulk queue (EnableBulkQ=No) is probably not relevant. (If you are frequently making HTTP submissions to blocks of more than 10,000 recipients, I would still recommend trying this setting.) Since the SMSOUT callbacks appear to be causing the performance bottleneck, the only thing we can think of trying is allocating more threads in NowSMS to processing them. Currently, when SMPP async mode is enabled for a connection, there is one thread per connection that gets woke up each time the SMSC indicates that it has accepted a message. It logs that information, and performs the accounting callback. As the accounting callbacks for messages sent out via a particular SMSC connection are processed sequentially, this may limit the speed at which messages can be sent out that connection. What we could do ... at least on an experimental basis, is allow additional threads to be allocated for processing the accounting callbacks. Whether or not it's going to help your situation, we don't know ... as we're having a problem replicating a similar situation. But theoretically, if this is where the bottleneck is, more threads could be helpful. A configuration setting is going to be included in the next update. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1020 Registered: 08-2008 |
Hi Alex, I wanted to follow-up with you ... we did put in an INI file parameter to allocate additional threads to the SMSOUT accounting callback processing. This is in the 2009.07.09 release: * SMS Gateway: Add configuration option to allocate more threads for managing SMSOUT accounting callbacks in SMPP Async mode environments. This may be necessary when using accounting callbacks over higher speed connections. To allocate additional threads, edit SMSGW.INI, and under the [SMSGW] header add AsyncCallbackThreads=##, where ## is the number of additional threads to allocate per async SMPP connection. -- Des NowSMS Support | |||
