When choosing a TLS library, two questions come up again and again: how much memory does it use and how fast is it. This post focuses on memory, comparing the heap usage of wolfSSL against several OpenSSL releases for an identical TLS 1.2 handshake. All numbers below were regenerated with current releases; wolfSSL 5.9.1 versus OpenSSL 1.1.1w, 3.0.0, and 4.0.0. The numbers were collected using Valgrind’s massif heap profiler inside a reproducible Docker container.
How we measured
To keep the comparison fair we wrote a single TLS client program against the OpenSSL API and compiled it, unchanged, against each library in turn. Building it against wolfSSL uses wolfSSL’s OpenSSL compatibility layer (–enable-opensslextra), so the exact same source code drives every library. There is no hand-tuned wolfSSL path versus a generic OpenSSL path. Each build connects to a common server peer using the ECDHE-RSA-AES256-GCM-SHA384 cipher suite over TLS 1.2, and we record peak heap usage with:
valgrind --tool=massif ./tls_client_mem 127.0.0.1 11111 1 \
ECDHE-RSA-AES256-GCM-SHA384 ca-cert.pem
The wolfSSL builds used:
# Default OpenSSL-compatible build ./configure --enable-opensslextra # Minimal-footprint build (small SP math) ./configure --enable-opensslextra --enable-sp-math-all=small --enable-sp=small
Memory at a glance
The chart below puts every measurement side by side. Peak heap for a single connection on the left, and the incremental memory cost of each additional live connection on the right. wolfSSL (green) sits far below every OpenSSL release on both metrics.
Heap usage, one connection
Peak heap for a single completed handshake:
| Library / build | Peak heap | ||
|---|---|---|---|
| OpenSSL 3.0.0 | 933.3 KB | ||
| OpenSSL 4.0.0 | 725.3 KB | ||
| OpenSSL 1.1.1w | 270.0 KB | ||
| wolfSSL 5.9.1 (–enable-opensslextra) | 43.3 KB | ||
| wolfSSL 5.9.1 (small SP math) | 38.5 KB |
wolfSSL uses a small fraction of the heap that OpenSSL requires for the same handshake, roughly 6–24× less, depending on the OpenSSL release. The massif graphs below tell the same story visually; note the dramatically different y-axis scales (wolfSSL peaks in the tens of KB while OpenSSL runs into hundreds of KB).
Heap usage, per connection
A single-handshake number bundles two very different costs together: the one-time setup a process pays once (library init, the SSL_CTX, loaded certificates) and the incremental cost of each additional live session. For a server juggling thousands of simultaneous clients, that per-connection cost is what actually determines how far the hardware scales.
To isolate it we ran the same harness holding 11 simultaneous TLS sessions open at once, then subtracted the single-session peak and divided by ten:
per-connection memory = (peak at 11 sessions − peak at 1 session) / 10
| Library / build | Per-connection memory |
|---|---|
| OpenSSL 4.0.0 | 62.8 KB |
| OpenSSL 3.0.0 | 55.2 KB |
| OpenSSL 1.1.1w | 53.7 KB |
| wolfSSL 5.9.1 (–enable-opensslextra) | 16.1 KB |
| wolfSSL 5.9.1 (small SP math) | 16.2 KB |
Each additional live TLS session costs wolfSSL about 16 KB, versus 54–63 KB for OpenSSL. Roughly 3 to 4 times less per connection. Because the per-connection figure strips out the fixed startup overhead, it is the most useful number for capacity planning: multiply it by your expected concurrent connection count to estimate the TLS memory footprint of a deployment. At 10,000 concurrent connections, for example, that difference is on the order of ~160 MB for wolfSSL versus ~540–630 MB for OpenSSL.
Performance
Both libraries ship assembly optimizations for Intel (AVX, AES-NI) and ARMv8. wolfSSL additionally provides hardware-acceleration support for embedded targets such as STM32, PIC32MZ, and others where OpenSSL has none.
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now