TPS Calculation for SMS / SMPP Application

Being in Enterprise Messaging Platform Business for more than a decade, we always receive this question from various enterprises on how we calculate the TPS of my platform.

How do I calculate the Throughput / TPS of the SMS/SMPP application?

TPS (Throughput Per Second) is one of the most important aspects of any enterprise messaging entity. Having high TPS is always desirable, however, many times we tend to make a mistake while calculating the inbound and outbound TPS of our system.

It may be noted that the TPS of any system depends on multiple factors and should be calculated with ideal conditions of CPU, RAM, and network.

A typical client server TPS can be measured between network to network or application to application or a mix of both. The following example explains TPS between a Client Application to an SMPP Server at Network Stack.

Mainly there are 3 parameters that define your overall throughput per sec / TPS.

Latency (in milliseconds)

Round-trip delay time the one-way time from the source (SMPP Client / ESME) sending a packet to the destination (SMPP Server / SMSC) receiving it plus the one-way time from the destination (SMPP Server / SMSC) sending a response packet back to the source (SMPP Client / ESME) receiving it, including the amount of time that a destination system (SMPP Server / ESME) spent in processing the packet at SMSC.

Window Size

It is relevant for asynchronous protocols (such as SMPP) and defines the max allowed number of unacknowledged packets that can be in-network pipeline ).

Number of Sessions

In order to make use of the SMPP Protocol, an SMPP session must be established between the ESME and Message Centre or SMPP Routing Entity.

Let’s understand the flow of SMS again

Step 1: SMPP Client (ESME) sends out SMS traffic to an SMPP Server (SMSC).

Step 2: SMPP Server Application acknowledges SMS to the SMPP Client

Step 3: SMPP Client sends out the SMS traffic with the help of SMPP Protocol (TCP / IP) via biding TCP/SMPP sessions connecting to the SMPP Server.

Here is a mathematical formula to design your application TPS:

TPS = Window Size * Number of Sessions / Latency

Setting up the following parameters will be able to generate a TPS of 500 SMS / Second

Window Size = 10

Number of Sessions = 5

Latency = 100 milliseconds (0.1 seconds)

TPS = 10 * 5 / 0.1 = 500 SMS / Second

According to individual needs, TPS can be set and monitored.

Setting a high value of windows size is not recommended due to following reasons:

1. Sending more async messages to the server will trigger more async responses on the client-side. This may trigger high CPU usage because you need to process all PDUs received in your network stack (receive buffer).
2. Any abrupt (non-graceful) socket disconnection may result in message loss which may be near equal to windows size.

We also discourage using a lot of sessions in your application as sessions are highly resourced intensive.

Final Thought

Instead of overloading your application to meet higher TPS requirements, you can plan horizontally scaling your system.

You may also refer the blog : Open Source SMPP Application: Scaling Out

You read this article on scaling.

You can reach out to me in case you have any specific query at dk.yadav@hexwireless.com