Messaging Performance
Raw Results
In local machine loop test libraries reach:
- 3645 msg/sec (synchronous)
- 11155 msg/sec (asynchronous)
Does this say a lot about performance of the libraries?
Not really. Local loopback test omits a lot of things that have to be considered in real life messaging. Probably it is most related to the performance of the machine used in the test. It is however a clear indication that the libraries certainly allow very high performance messaging.
Performance Testing
Recent versions of our SMSC Server Library library provides a compiled demo application which allows to easily test basic performance of the client/server library combo in real life situations.
To test the performance start desired protocol demo application and change the dropdown box switch over the Event log area to Statistics.
Once you connect to the application and submit some messages the application will report number of messages received per second in one second intervals. Statistics will be reported if the number of messages submitted/delivered is greater than 0.
Results of a local machine loop test in synchronous mode:
Results of a local machine loop test in asynchronous mode:
What influences messaging performance?
Many things actually:
- TCP/IP connection's bandwidth and delay it introduces (delay is often neglected but it has to be added to every single package's roundtrip).
- Size of the complete message PDU, because it both takes time to encode and decode.
- Size of the payload message carries (message size, optional fields, extended parameters etc.)
- Performance of the machine that is used to run the messaging software.
And, most importantly, the performance of the SMSC that the libraries cooperate with.
SMSC's Limitations
In real world, there barely exists an SMSC that can accept more than 100-150 messages per second on a single, public TCP/IP connection. At least we have not meet many with all the experience we have. In protocols like SMPP when client submits too many messages per second SMSC starts returning non fatal errors like:
0x00000058 Throttling error (ESME has exceeded allowed message limits)
Such error code means that the SMSC has accepted the message to further processing but client should slow down submitting subsequent messages.
Best way to cope with such a situation is to use throttling feature built in the libraries which ensures that the limit that is imposed by the SMSC is never exceeded.