Web Interface Submission Speed

Web Interface Submission Speed SearchSearch
Author Message
DJXLoRd
New member
Username: Djxlord

Post Number: 6
Registered: 01-2004
Posted on Sunday, February 19, 2006 - 04:12 pm:   

Dear Sir ,
we have been using nowsms for quiet sometime now and we have been monitoring performance from many aspects , one note though keeps hanging when submitting a large amount of SMS througha Dist. List , Creation time of Que takes a long time , thus causing a delay in delivery yet we are having a high throughput SMSC connection , is there faster way to submit large amounts of SMS yet faster in Queue creation.
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 5591
Registered: 10-2002
Posted on Friday, March 03, 2006 - 10:04 pm:   

This is an area that we optimised in preparation for the NowSMS 2006 release.

What I am unsure of is whether or not there might be a v5.51 patch that includes some of this optimisation.

v5.51k (http://www.nowsms.com/download/latestpatch.zip) definitely does not include this optimisation.

But I think there may be a more recent patch where this optimisation may have snuck in. The walter.zip patch referenced in the following thread: http://support.nowsms.com/discus/messages/1/12836.html

Give it a try. I believe the speed up for processing a large dlist snuck into that version.

Otherwise, give the NowSMS 2006 trial a try.

How many entries in a Dlist are we talking about?
DJXLoRd
New member
Username: Djxlord

Post Number: 7
Registered: 01-2004
Posted on Sunday, March 05, 2006 - 01:46 pm:   

Dear Bryce ,
Is it ok to apply the Walter Patch over 5.51 K or this is considered a downgrade , so i dont lose all features of 5.51K
DJXLoRd
New member
Username: Djxlord

Post Number: 8
Registered: 01-2004
Posted on Sunday, March 05, 2006 - 01:56 pm:   

we are talking about 20K , 40K , 60K entries per list..
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 5603
Registered: 10-2002
Posted on Monday, March 06, 2006 - 10:33 pm:   

Yes. The walter.zip patch is a later version than 5.51k.

It's a good idea to back up EXE and DLL files before trying the update, then you can always go back if necessary.
ashot shahbazian
Frequent Contributor
Username: Animatele

Post Number: 60
Registered: 06-2004
Posted on Thursday, March 16, 2006 - 02:33 am:   

We've tested NowSMS throughput issues last fall. As far as I remember, v.5.51h was many times faster than some previous releases. We've reached speeds of over 200 SMS/sec over SMPP in synchronous mode between 2 common P-IV computers running Windows XP Pro in a LAN, after some tweaking. Try the following:

-Use a dedicated machine with a new clean "minimised" OS install, no other software loaded.

-disable ALL unnecessary services running on your server. Information on what can be safely disabled can be found by searching for relevant terms on Google. After reboot, your system should consume between 80 and 95 megabytes.

-disable the swap file. You can do it even if your computer has only 256mB of RAM, but 512 would be safer.

- Defragment the disks every day (set a task in Task Scheduler.) NowSMS records a lot of information , which fragments the disks very quickly. In our experiments, throughput after day's worth of fragmented logs was down by about 25%.

-check the ping (tracert if you can't ping it) to the IP address of your MNO-s ESME. If it's over 5-10 ms (you are in the same town and your server is colocated at a major telehouse) you must use asynchronous mode. To use it properly, you should contact the MNO and find out what they recommend as optimal Window Size.

The issue with large batches:

- use a high-performance server with Windows 2003 or 2000 server OS and SCSI disks with a caching controller. Windows XP has trouble managing more than 65,000 files in one directory.

- Use a dedicated server for processing large batches. The purpose of that is to avoid activating any routing preferences in NowSMS. If you have a single SMSC bind and all of your messages come from a single user and route by defaul to that single bind it will greatly reduce the CPU load.

BTW, should you ever need real-time HLR scans for those large batches, inexpensively, please contact me on info@coolmessages.net