| Maximum Optimum List Size |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through April 05, 2007 ⬆ |
◄ ► |
| Author | Message | |||
| Rhea New member Username: Rhea Post Number: 1 Registered: 08-2006 |
Dear Bryce, I have a list size of 0.3 Million numbers, and i wanted to know if the size of the list affects the performance of NowSMS, and if it does what is the recommended list size? | |||
| Rhea New member Username: Rhea Post Number: 4 Registered: 08-2006 |
Any recommendations? | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6414 Registered: 10-2002 |
Hi Rhea, That is a good question. One that I should have a very quick answer for you on ... but to be honest, I haven't run any tests like this for awhile. So I've been running some tests today, and trying to explain some of the stranger results that I've seen. Bottom line ... for fastests performance on bulk submissions (the same message to an extremely large number of recipients), disable "SMS Users" accounts if practical for your environment. Limit access instead through allowed IP addresses. (This is done by UNchecking "Require authentication for web interface" on the "Web" page of the NowSMS configuration, in addition to using the "IP Address Restrictions" form on that same page.) Basically, there are some inefficiencies in the user logging which can slow down a bulk submission. And this will disable the user logging. I need more time to fully investigate this. Still, it doesn't seem to be that big of a deal, because even though the bulk submission into NowSMS is slower than it should be ... it is still much faster than an upstream SMSC will accept the messages. In the big picture, this does not seem to be a problem, because the submission part is not where the bottleneck is. But what can be a problem is that if you submit to a large list via HTTP, the submitting client might timeout waiting for a response. I'll have more on this tomorrow, or the next day, after I complete some more tests. -bn | |||
| Rhea New member Username: Rhea Post Number: 7 Registered: 08-2006 |
Dear Bryce, The current case is as follows: Our application (ASP.NET) submits via HTTP the Bulk SMS Content and the List Name (found in DLIST Folder) to the NowSMS. The list contains 0.3 Million Numbers and what happens is like what you said that the submitting client times out waiting for a response. I hope there might be a workaround for this. | |||
| Rhea New member Username: Rhea Post Number: 8 Registered: 08-2006 |
Dear Bryce, Is there another method besides using the Distribution List for sending Bulk SMS that would be more efficient, i.e. faster for creating the Q Files. Also, is HTTP the only method that an application can submit sms to the NowSMS or is there an API or Dll or something else besides HTTP? | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6419 Registered: 10-2002 |
Hi Rhea, For your purposes, the best alternative may very well be to create the Q files directly. I have been running some tests, and the delay in the HTTP response does not grow linearly as the list size increases. For example, I saw a 3 minute, 48 second response delay for 50,000 recipients, and over 30 minutes for 300,000 recipients. We've been doing some preliminary engineering work that trims those times down to 1 minute, 35 second delay for 50,000 recipients, and 9 minutes, 30 seconds for 300,000 recipients. That's better ... as 6 times the number of recipients should take no more than 6 times the amount of time to process. However, that is still too long of a delay for a response in an HTTP transaction. It is my opinion that we need to change this. Anything over a certain number of recipients should go into a separate bulk Q that can better deal with a large number of recipients. That's something that we need to work on, and I can't give you a quick change for this. In your case, based upon information in other threads that you have started here, it looks like your messages are in Arabic, and typically require being sent out as 2 part messages. So instead of 300,000 messages, 600,000 need to be generated if the message contains 2 parts. There is no DLL API ... you could create Q files directly. But if you do, and they are in Arabic, the Q file would need to have the message data in Unicode format. And if the Unicode text is longer than 70 characters, you would need to segment it and put in the appropriate UDH. (View existing files in the Q directory to understand this.) Also, to avoid having 600,000 files in a directory, you should create subdirectories under the Q dir. You can only go one level deep with subdirs, but you'll see better performance if you don't put more than 10,000 to 20,000 files in a single one of these subdirs. NowSMS will still pull the files out of the subdirs. (At least 2006 will, not sure about earlier versions.) But it's a lot of work to create these Q files manually, especially if you have to do the segmentation. It might be better off just making the HTTP request and letting it time out ... just having your application assume that it was successful. -bn | |||
