Throughput is an outcome, not a spec: the messages a gateway actually delivers per minute depend on ports, SIMs, carriers, message length, encoding, and the software queue. This page explains how those variables combine into transactions per second (TPS) and how to measure the number honestly on the SMS gateway you evaluate.
Throughput vs Delivery Rate
Throughput is how fast messages are submitted and delivered per minute, while delivery rate is what percentage reach handsets. A gateway can push huge volume and still fail delivery, so the two numbers must be measured together rather than quoted separately.
The distinction matters in reporting. A campaign that shows high submitted-per-minute but low delivered-per-minute has a delivery problem, not a throughput problem, and the fix belongs in SIM health, content, or routing rather than in hardware capacity. Keeping the two metrics separate in your dashboards prevents the common mistake of tuning the wrong layer.
Where TPS Actually Comes From
Each GSM port sends serially: submit, wait for the network, submit again. That per-port rate, multiplied by ports and divided by how long each message ties up the module, is the practical ceiling.
Three variables push it down: SIM throttling limits per-SIM volume so the pool size decides headroom; message length and encoding split long or Unicode messages into segments that each count as a transaction; and queueing and pacing smooth bursts while setting the actual send rate.
A 64-port system approaches roughly 5,400 to 5,500 messages per minute (product-rated ceiling) only when SIMs and carriers cooperate; real numbers land lower and vary by market.
A capacity example: if a carrier's SIM accepts 50 messages per minute and the gateway has 16 healthy SIMs, the practical ceiling is about 800 messages per minute before considering signal and queue effects. That is why port count alone is meaningless; the SIM plan and the carrier are half of the equation.
Asking the supplier to state which SIM count and plan their throughput figure assumes is the fastest way to compare claims.
| Variable | Effect on throughput |
|---|---|
| Ports | Number of parallel send paths |
| SIM pool | Throttling headroom |
| Message length / encoding | Segments per message |
| Queue and pacing | Actual send rate and burst smoothing |
| Carriers | Per-SIM and network limits |
Why Segments Matter
Carriers bill and count segments, not logical messages. A 160-character GSM-7 message is one segment; the same text with a single emoji becomes three UCS-2 segments. Throughput measured in messages hides this, so always count segments when testing capacity.
Segment counting changes capacity planning in a concrete way: a campaign whose average message runs 180 characters with a personalization field will often split into two segments, doubling the transaction count against the SIM and the carrier. Measuring throughput in logical messages understates the load by the average segment count, so record both in the benchmark.
The billing consequence is separate from throughput, but it follows the same math. Carriers charge per segment, so a campaign that doubles its segment count also doubles its cost while consuming twice the SIM volume. Knowing the average segment count per campaign lets you forecast both cost and capacity from the same number, which makes it one of the most useful figures in an SMS operation.
The Queue Is a Throughput Governor
Without a queue, applications push bursts straight into carrier throttling. The queue paces submissions at a safe rate per SIM and retries failures with backoff, so it protects delivery but also sets the practical ceiling. Throughput tests that bypass the queue measure the radio rather than the system, and the system is what you operate.
Queue behavior is a design choice, not a default. A queue with no limit accepts everything and builds latency; a queue with a strict limit rejects messages under burst load; and a queue with per-SIM pacing holds messages until each SIM can accept them. Choose the behavior that matches the traffic: transactional traffic wants low latency and bounded queues, campaign traffic tolerates pacing in exchange for stability.
How to Measure Honestly
Load the gateway with your SIMs and a test list of numbers you control, send at increasing rates, and log submitted versus delivered per minute. Record conditions such as message length, encoding, SIM count, signal, and time of day. Run over multiple hours and days rather than one burst, and compare delivered TPS and delivery rate together.
For a full acceptance protocol with KPIs and reporting, use the benchmark test template in this series, and match results to the SMS gateway product line tiers.
Run each measurement at the time of day your real traffic peaks, repeat it across days to absorb carrier variability, and record the exact message length and encoding so the results are comparable across vendors. A 10-minute test at noon on a perfect network proves nothing about a Thursday-evening campaign burst; the acceptance number that matters is delivered TPS at your peak with your SIMs.
Reporting the benchmark also matters. Keep the conditions, the submitted-versus-delivered numbers, and the delivery rate per run in one table, and attach the failure-code breakdown so the results are auditable. A benchmark without a report is a rumor; with a report, it is evidence that survives a procurement review and supports the acceptance decision.
For resellers, the same benchmark data becomes a sales asset: a documented delivered-TPS figure per model, per SIM plan, and per market gives customers a realistic planning number instead of a marketing ceiling. Publishing the conditions alongside the number is what keeps the claim credible.
The relationship between capacity and delivery deserves its own reminder: throughput buys speed, not success. A gateway that can push 1,000 messages per minute still fails delivery if the SIMs are throttled, the content is filtered, or the queue is misconfigured. Measure both numbers, report both numbers, and treat a throughput upgrade as a capacity change rather than a delivery fix.
One more planning note: throughput requirements grow unevenly. A campaign that doubles its volume does not need double the ports if it runs twice as long, while a notification service with a fixed peak window does. Model the peak window, not the annual volume, when you decide whether to add ports or extend the sending window.
The same logic applies to SIM costs: adding SIMs raises monthly recurring cost even when ports are idle, so the decision between more ports and longer windows is a cost decision as well as a capacity one. Extending the sending window is free; adding ports is a purchase; and the right answer depends on whether your traffic can tolerate a longer window or must clear a fixed peak.
Whichever path you choose, record the decision with its reasoning. Capacity decisions made twice a year deserve a one-line note about volume, window, and cost, because that note is what keeps the next capacity review from starting from zero.
The same habit applies to benchmarks: keep every run's report, not just the best one. A library of benchmark reports shows how throughput changed as SIMs, carriers, and software were updated, and that history is the evidence base for the next capacity decision.
Telarvo Expert Views
Throughput claims are only as good as their test conditions. The numbers that survive scrutiny are delivered TPS measured on the buyer's SIMs and carriers over a full day, with message length and encoding recorded. Everything else is a marketing figure.
— Messaging Solutions Engineer, Telarvo Store
Validation note: product-rated ceilings in this article are manufacturer figures under specified conditions; validate on your own deployment.
Conclusion
Throughput is a combination of radio capacity, SIM limits, segments, and queue policy, and measuring it honestly requires delivered TPS plus delivery rate under recorded conditions.
Key Takeaways for B2B Buyers
Measure delivered TPS with delivery rate, count segments rather than logical messages, keep the queue in the test, record conditions, and compare results across a full day.
Questions to Ask Before Committing
Ask what conditions a throughput figure was measured under, how segments are counted, and whether the test included the production queue.
FAQs
What is the difference between TPS and delivery rate?
TPS is how fast messages are processed; delivery rate is what percentage reach handsets; both belong in any capacity claim.
Why do long messages reduce throughput?
Long messages split into multiple segments, and each segment is a separate transaction against the network and the SIM's volume limit.
How do queues affect throughput?
Queues smooth bursts and pace sends per SIM, protecting delivery while setting the practical ceiling; test with the queue in place.