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.
