Every bulk SMS business eventually hits the same wall. A campaign that should finish in 10 minutes takes forty, OTPs arrive late, and the supplier says you are “over your TPS.” Understanding transactions per second is the fix, because it decides how fast your platform can push traffic into an operator network.
This blog explains what TPS and MPS mean, how they differ from delivered throughput, how to calculate the capacity you need, and what to check when you evaluate an SMS gateway or wholesale sms platform.
Quick Answer
Transactions per second (TPS) counts how many protocol requests, usually SMPP submit_sm operations, a connection sends or processes each second. Messages per second (MPS) counts how many complete SMS messages are handled each second. They match only when every message fits in one segment. Long or Unicode messages split into several segments, so required TPS is often higher than MPS.
Key Takeaways
- TPS measures protocol operations per second. MPS measures whole messages per second. Segmentation makes TPS equal to or greater than MPS.
- Your effective speed is capped by the lowest limit in the chain: your gateway, your SMPP bind window, your supplier’s per bind limit, or the destination operator’s SMSC.
- On an SMPP bind, maximum TPS is roughly window size divided by round trip time to the SMSC.
- Size capacity from your peak burst and your deadline, not your daily average.
- Higher TPS does not guarantee faster delivery. Operator throttling, queue depth, and handset reachability still apply.
What Does TPS Mean in Bulk SMS?
Transactions per second in bulk SMS is the number of request and response operations a messaging component can process in one second. In SMPP, the most common transaction is a submit_sm request that sends one message segment, followed by a submit_sm_resp acknowledgement from the receiving SMSC.
Short Message Peer to Peer (SMPP) is the protocol most A2P platforms use to exchange messages with a Short Message Service Center (SMSC). The external application connecting to the SMSC is called an ESME. When an aggregator connects to an operator, the aggregator acts as the ESME and the operator’s SMSC is the server.
TPS appears in three places in a bulk SMS business:
- Your own gateway: how many submissions it can accept from customers and route onward.
- Your supplier bind: the limit your upstream operator or aggregator sets per connection or per account.
- The destination network: the rate at which the final SMSC accepts and delivers traffic.
The same word covers all three, which is why conversations about TPS go wrong. Always ask which link is being described.
TPS vs MPS vs Throughput
TPS counts protocol transactions, MPS counts messages, and throughput describes how many messages actually reach handsets over time. A platform can have high TPS and poor throughput if the operator queues or delays delivery downstream.
| Metric | What it counts | Where you see it | Typical use |
| TPS | Protocol requests per second (for example submit_sm) | SMPP binds, supplier contracts | Connection and gateway capacity |
| MPS | Whole SMS messages per second | Campaign planning, customer SLAs | Business level speed targets |
| Delivered throughput | Messages confirmed delivered per unit of time | DLR reports | Real campaign performance |
The key takeaway: TPS and MPS describe how fast you can submit. Delivered throughput describes what the network actually did with it. Contracts and capacity plans should state which one they mean.
Why segments push TPS above MPS
A single SMS carries up to 160 characters in the GSM 7 bit alphabet, or 70 characters in UCS2 for scripts such as Arabic or Hindi. Longer texts are concatenated into segments of 153 characters (GSM 7 bit) or 67 characters (UCS2), because part of each segment carries a concatenation header.
Each segment is typically submitted as its own submit_sm. A 300 character English message becomes two segments, so one message costs two transactions. Traffic to the UAE, Africa, and Southeast Asia often includes Unicode content, which makes this effect larger than most teams expect.
How TPS Works on an SMPP Connection?
On SMPP, a persistent connection called a bind carries submissions and acknowledgements. The sender does not have to wait for each response before sending the next request. The number of requests allowed to be unacknowledged at once is the window size.
A simple sequence:
- Your gateway sends submit_sm requests up to the window limit.
- The SMSC returns a submit_sm_resp for each one, which frees a window slot.
- The gateway sends new requests into the freed slots.
- Later, the SMSC sends deliver_sm messages carrying delivery receipts (DLRs) and any mobile originated messages.
This produces a practical ceiling:
Maximum TPS per bind is approximately window size divided by round trip time in seconds.
Hypothetical example: with a window of 10 and a 100 millisecond round trip, one bind tops out near 100 TPS. With a window of 50 and a 50 millisecond round trip, the same bind tops out near 1,000 TPS. Moving a gateway closer to the operator, or raising the agreed window size, can matter as much as buying a bigger server.
Note that deliver_sm traffic also consumes capacity. Many suppliers count receipts against the same connection limits, so a bind that “does 100 TPS” may submit fewer than 100 messages per second once DLRs flow back.
How to Calculate Transactions Per Second for Bulk SMS
Required TPS equals total segments to send divided by the seconds you allow, adjusted for peak and retries. Work through it in four steps.
Step 1: Count messages and deadlines. Decide how many messages must go out and in what time. Hypothetical campaign: 1,000,000 messages in 10 minutes (600 seconds).
Step 2: Find required MPS. 1,000,000 divided by 600 is about 1,667 MPS.
Step 3: Convert to TPS using average segments. If the average message uses 2 segments, the required TPS is about 3,334. If every message fits in one segment, TPS equals MPS.
Step 4: Add headroom. Add a margin for retries, DLR load, and uneven traffic. Many engineers plan 20 to 30 percent headroom, though this is a rule of thumb, not a standard. Here that suggests around 4,000 TPS.
Then work backwards to binds: if each supplier bind allows 500 TPS, you need at least eight binds spread across routes, or a supplier willing to raise per bind limits.
The mistake to avoid is dividing by a full day. Messaging load is bursty, and your capacity must cover the peak.
What TPS Does a Bulk SMS Business Need?
There is no universal figure, and anyone quoting one without context is guessing. The right number depends on peak volume, deadlines, segment count, and the number of destinations. These are rough planning bands based on typical business models, not published benchmarks:
| Business type | Traffic pattern | Capacity driver |
| Enterprise (alerts, OTP, reminders) | Steady with sharp spikes | Peak OTP bursts, login events |
| Marketing sender | Large scheduled blasts | Campaign deadline |
| SMS aggregator or reseller | Many customers, mixed content | Sum of customer peaks across routes |
| Wholesale carrier or hub | Very high, multi destination | Per destination, per operator limits |
For a business in the USA, remember that outbound speed is also shaped by how traffic is registered and carried. Throughput on US application to person routes is influenced by carrier and registry rules for the number type you use, such as 10DLC or toll free. These limits change over time, so confirm current figures with your provider.
How TPS Affects OTP and Alert Delivery?
Insufficient TPS creates queues, and queues add delay. OTP and alert traffic is time sensitive, so even a short queue can break the experience.
Consider a hypothetical bank that normally sends 20 OTPs per second, but a promotion triggers 400 login attempts per second for five minutes. If its gateway and routes sustain only 100 TPS, the excess builds a backlog of about 90,000 messages (300 extra per second for 300 seconds). Later users wait minutes for a code that expires in 60 seconds.
Two practical protections:
- Separate traffic classes: Put OTP and alerts on dedicated binds or priority queues so a marketing blast cannot starve them.
- Set message validity periods: An expired OTP should be dropped, not delivered late.
Why Connections Get Throttled
Throttling is how an SMSC protects itself from traffic it cannot handle. When a sender exceeds an agreed rate, the SMSC may reply with an SMPP error such as ESME_RTHROTTLED (0x58), or ESME_RMSGQFUL (0x14) when its message queue is full.
Common causes:
- Submitting faster than the agreed per bind TPS
- Ignoring window size limits
- Aggressive retries that multiply load during an incident
- Bursts after a downtime recovery, when queued traffic releases all at once
- DLR volume not accounted for in the limit
Handle throttle errors with backoff and rate shaping, not immediate resubmission. Retrying instantly makes the problem worse and can lead the supplier to cut the bind.
Can a Bulk SMS Business Increase Its TPS Capacity?
Yes, but only after you find the actual bottleneck. Raising your gateway’s capacity does nothing if the supplier limit is the constraint.
Work through the chain in this order:
- Measure each link: Compare submitted rate, submit_sm_resp latency, and DLR return rate per route.
- Tune the window size: If latency is the limit, a larger window can raise TPS without a new bind, provided the supplier allows it.
- Add binds: Multiple binds to the same SMSC multiply capacity where the limit is per connection.
- Reduce segments: Trim templates and avoid unnecessary Unicode characters to cut transactions per message.
- Negotiate with suppliers: Ask for higher per bind or per account limits, with evidence of your traffic quality.
- Distribute across routes: Spread traffic over several suppliers so no single limit caps you.
- Scale your own gateway: Add processing and queue capacity once the upstream links have room.
The trade off: more binds and routes raise capacity but add operational overhead, monitoring needs, and cost.
What to Evaluate in a High TPS SMS Gateway?
If you are an aggregator or enterprise choosing software, ask for evidence on these criteria rather than accepting a headline number:
| Criterion | Question to ask |
| Rated TPS | Under what test conditions: segments, DLRs enabled, persistence on? |
| Sustained vs burst | How long can the rate be held? |
| Per bind controls | Can window size and rate limits be set per connection? |
| Queueing | How are queues prioritized and persisted during a route outage? |
| Throttle handling | Does it apply backoff on throttle errors automatically? |
| Routing | Can it shift traffic across suppliers when one slows down? |
| Monitoring | Does it show TPS, latency, and DLR rates in real time? |
| Scaling model | Does capacity grow with added hardware or licenses? |
Organizations that need these capabilities can evaluate TeleOSS SMS Gateway Software for managing SMPP connectivity and message flow, and the TeleOSS SMS Wholesale Solution for operators and aggregators that carry traffic for other businesses. Confirm rated TPS, test conditions, and supported routing features directly with the team for your deployment. A benchmark run on your own traffic mix is more reliable than any brochure figure.
Common Mistakes
- Treating TPS and MPS as the same number: Multi segment messages break this assumption.
- Sizing from daily averages: Peaks decide whether you queue.
- Ignoring DLR load: Receipts consume connection capacity.
- Retrying instantly on throttle errors: It deepens congestion.
- Mixing OTP with bulk marketing on one bind: A campaign can delay critical codes.
- Buying capacity before finding the bottleneck: The limit is often a supplier cap or a small window.
Conclusion
Transaction per second in a bulk SMS business is a capacity measure for how fast protocol requests move between your platform and operator networks. MPS counts messages, TPS counts the segment level transactions behind them, and delivered throughput tells you what the network actually did. Size for peak load and segment count, find the true bottleneck before spending, and keep time critical traffic apart from bulk campaigns.
If you are sizing a gateway or planning wholesale capacity, talk to the TeleOSS team. Share your peak volume, average segments, and destination mix, and ask for a capacity assessment of your SMPP setup.
FAQs
What does transactions per second (TPS) mean in bulk SMS?
TPS is the number of protocol operations, typically SMPP submit_sm requests, that a connection or gateway handles per second. Each message segment usually counts as one transaction. It describes submission capacity, not how fast messages reach handsets.
How is TPS different from throughput in SMS gateways?
TPS measures how many requests a system processes per second. Throughput is the volume of messages that actually completes delivery over time. A gateway can submit at high TPS while operator queues, throttling, or handset issues keep delivered throughput lower.
What TPS does a bulk SMS business typically need?
It depends on peak volume, deadline, and segments per message. Divide total segments by the seconds you allow, then add headroom for retries and delivery receipts. A business with steady alerts needs far less than one sending million message campaigns on a short deadline.
How does TPS affect OTP and alert delivery speed?
If traffic exceeds available TPS, messages queue and arrive late. OTPs often expire within a minute or two, so queue delay can make them useless. Dedicated binds, priority queues, and short validity periods reduce this risk.
Can a bulk SMS business increase its TPS capacity?
Yes. Identify the bottleneck first, then raise the window size, add binds, reduce segments, negotiate higher supplier limits, add routes, or scale the gateway. Increasing your gateway alone will not help if the supplier’s per bind limit is the cap.
How do I calculate transactions per second for an SMPP connection?
Estimate the ceiling as window size divided by round trip time in seconds. A window of 20 with a 100 millisecond round trip gives about 200 TPS. Your real rate also depends on the supplier’s agreed limit and delivery receipt traffic.
