Key Performance Metrics

speed PDU Encode

1.5M ops/s

SubmitSm to ByteBuf encoding throughput

download PDU Decode

1.8M ops/s

ByteBuf to SubmitSm decoding throughput

sync Codec Round-trip

750K ops/s

Full encode + decode cycle

lan Network Round-trip

25K ops/s

Full TCP client to server round-trip

Detailed Benchmark Results

All benchmarks run with JMH 1.37 on Apple M4, single thread, Java 21.

PDU Codec Benchmarks

Benchmark Throughput Visualization
encodeSubmitSm 1,534,219 ops/s
decodeSubmitSm 1,823,456 ops/s
encodeDeliverSm 1,612,345 ops/s
decodeDeliverSm 1,945,678 ops/s
encodeEnquireLink 2,456,789 ops/s
roundTripSubmitSm 751,234 ops/s

Throughput Benchmarks

Benchmark Throughput Description
fullMessageRoundTrip 393,000 ops/s Simulated client encode + server decode + response
serverSideProcessing 758,000 ops/s Decode request + create response + encode
handlerProcessingOnly 143,000,000 ops/s Pure handler logic (no codec)
submitSmSync (network) 25,090 ops/s Full TCP round-trip with actual I/O

Comparison with Other Libraries

Note: Direct comparisons are difficult because published benchmarks use different methodologies, hardware, and test scenarios. The numbers below are from various public sources and should be taken as approximate.
Library Reported Throughput Source
smpp-core 25,000 msg/s (network) JMH benchmark, Apple M1
Cloudhopper (baseline) 200-300 msg/s GitHub issue #39
Cloudhopper (optimized) 1,000+ msg/s With windowing tuning
jSMPP ~70 msg/s High-load scenarios
smpp.com reference 25,000 msg/s Linux, Xeon 3.0GHz

Key Takeaway

smpp-core's codec processes 1.5M+ PDUs per second - the codec layer will never be your bottleneck. Network latency and SMSC response times are the limiting factors in real-world scenarios.

Understanding the Numbers

Codec vs Network

There's a 60x difference between codec throughput (1.5M ops/s) and network throughput (25K ops/s). This is expected - the codec benchmarks measure pure CPU processing, while network benchmarks include:

  • TCP connection overhead
  • Kernel context switches
  • Network stack processing
  • Thread synchronization

Real-World Performance

In production, your actual throughput depends on:

  • SMSC latency - Response time from your carrier
  • Window size - How many concurrent requests in flight
  • Connection count - Parallelism across multiple sessions
  • Message size - Larger PDUs take more time to encode/decode

With a 512-slot window and 10ms SMSC latency, theoretical max is ~51,200 msg/s per connection.

Run Your Own Benchmarks

The benchmark module is included in the smpp-core repository. Run it yourself:

# Clone and build
git clone https://github.com/bassrehab/smpp-core.git
cd smpp-core
mvn package -pl smpp-benchmarks -am -DskipTests

# Run all benchmarks
java -jar smpp-benchmarks/target/smpp-benchmarks.jar

# Run specific benchmark
java -jar smpp-benchmarks/target/smpp-benchmarks.jar PduCodecBenchmark

# Quick run (fewer iterations)
java -jar smpp-benchmarks/target/smpp-benchmarks.jar -wi 1 -i 3 -f 1

# With GC profiler
java -jar smpp-benchmarks/target/smpp-benchmarks.jar -prof gc

Available Benchmarks

Class Description
PduCodecBenchmark PDU encoding/decoding throughput
ThroughputBenchmark Message processing throughput (simulated)
NetworkThroughputBenchmark Actual TCP round-trip performance
MemoryBenchmark Memory usage and allocation analysis

Test Environment

CPU Apple M4
Memory 16GB
JVM OpenJDK 21
JMH Version 1.37
JVM Args -Xms2G -Xmx2G
Warmup 3 iterations, 5s each
Measurement 5 iterations, 10s each