Performance
The following results were measured by the stunnel project on 14 July 2026.
Results
TLS 1.3 Data Throughput
| Ciphersuite | Client to server | Server to client |
|---|---|---|
TLS_AES_128_GCM_SHA256 |
10.67 Gbit/s | 10.64 Gbit/s |
TLS_AES_256_GCM_SHA384 |
10.44 Gbit/s | 10.10 Gbit/s |
TLS_CHACHA20_POLY1305_SHA256 |
9.32 Gbit/s | 9.12 Gbit/s |
The plaintext loopback baseline was 68.86 Gbit/s client to server and 69.08 Gbit/s server to client. The baseline confirms that the test path had substantially more capacity than the TLS tunnel.
TLS 1.3 Connection Establishment
| Handshake | Connections/s |
|---|---|
| Full handshake | 738 |
| Resumed session | 1,400 |
The full handshake used a 3072-bit RSA certificate, rsa_pss_rsae_sha256 signatures, the X25519MLKEM768 hybrid key-exchange group, and TLS_AES_128_GCM_SHA256. The resumed test reused TLS 1.3 sessions established by the same client.
Test System
- CPU: AMD Ryzen 9 7900 12-Core Processor (24 logical CPUs),
performancegovernor - Operating system: Linux-7.0.13-x86_64-with-glibc2.42
- stunnel: stunnel 5.79 on x86_64-pc-linux-gnu platform
- OpenSSL: OpenSSL 3.6.3 9 Jun 2026
- iperf3: iperf 3.20 (cJSON 1.7.15)
Methodology
Throughput Measurement
An iperf3 TCP stream traversed this local loopback path:
iperf3 client
-> stunnel client
-> TLS 1.3
-> stunnel server
-> iperf3 server
The stunnel client and server were each restricted to one separate physical CPU core. The iperf3 client and server each used another separate physical core. This measures a complete stunnel-to-stunnel tunnel without imposing a network-interface speed limit.
Each ciphersuite and traffic direction received a one-second warm-up followed by 5 samples of 10 seconds. The table reports the median values rather than the best samples.
Connection Rate Measurement
openssl s_time established sequential TLS connections to a server-mode stunnel instance. The OpenSSL client, stunnel server, and plaintext HTTP backend each ran on a separate physical CPU core. Each mode received a one-second warm-up followed by 5 samples of 10 seconds.
Scope
These results primarily measure single-stream cryptographic and proxy overhead on one processor generation. They do not measure network-interface limits, multi-core aggregate scaling, DTLS, mutual TLS, PSK, maximum concurrent connections, or memory per connection.
Production capacity also depends on connection lifetime, session-resumption rate, certificate policy, logging, backend latency, network behavior, operating-system limits, OpenSSL build options, and competing workloads. Capacity planning should therefore reproduce the production workload on the intended hardware.
The benchmark framework records every sample and the complete software environment so future stunnel and OpenSSL releases can be compared using the same procedure.
