lilleman
fb139ab5ee
Benchmarks
What this library sustains, and against what. Run them before setting or changing a scale goal.
docker compose run --rm node node benchmarks/run.ts # this library, both ends
COUNT=100000 docker compose run --rm node node benchmarks/run.ts # longer, steadier
run.ts spawns smsc-sink.ts — a server that answers every submit_sm ESME_ROK and stores
nothing — and drives it with submit-load.ts at four window sizes. Point submit-load.ts at any
SMSC to compare:
docker compose -f compose.yaml -f interop-tests/compose.jasmin.yaml run --rm node \
node benchmarks/submit-load.ts --host=jasmin --port=2775 --username=esme1 --password=esme1pw \
--count=20000 --concurrency=50
A short run measures the JIT, not the library. At 2,000 messages per point the same build reported 16k/s where 100,000 messages reported 40k/s. Give each point several seconds.
Results, 2026-09-20
Single host, 8 cores, Node 24.18.0 in the project container, loopback. Client and SMSC are separate processes competing for the same CPUs, so these are a floor for split hosts.
maxOutstanding is the send window, and it is the setting that matters most:
| Window | msgs/s | with dlr: true |
|---|---|---|
| 1 | 7,385 | 7,289 |
| 10 (default) | 25,358 | 24,282 |
| 50 | 37,125 | 37,502 |
| 200 | 40,046 | 39,730 |
Requesting delivery receipts costs nothing measurable at any window. A window of 1 — one request in flight at a time — costs 5x, which is the round trip rather than the codec.
Against real peers, same driver, window 50, 20,000 messages:
| SMSC | msgs/s | failed |
|---|---|---|
| this library's sink | 37,125 | 0 |
| Jasmin 0.10 | 2,207 | 0 |
| SMPPSim 3.0.0 | — | 19,000 of 20,000 |
Jasmin routes and persists where the sink does neither, so the gap is not an efficiency ratio between two comparable things — what it establishes is that this library is not the bottleneck against a production SMSC, by more than an order of magnitude. SMPPSim's store fills at roughly a thousand messages and it then refuses the rest, so it cannot be loaded; that is a property of the simulator, not a result.
smppload, the one purpose-built SMPP load generator among the peers, is blocked by a bind defect
of its own (findings/07-load.md), so no third-party load
tool drives these numbers.