SSL Offload Capacity Calculator
Size SSL/TLS offload cores separately for asymmetric handshakes and symmetric bulk encryption, including session resumption.
Inputs
Total Cores Required
2.76
Full Handshakes per Second
2,400
Cores for Asymmetric Handshakes
0.10
Cores for Bulk Encryption
2.67
CPU Utilisation
17.3%
Signing Operations per Core
25,000ops/s
Step by step
Values used
TLS handshakes per second = 6,000 handshakes/s; Certificate key type = ECDSA P-256; Handshakes resumed from a session ticket = 60 %; CPU cores available for TLS = 16 cores; Encrypted bulk throughput = 8,000 Mbps; AES-GCM throughput per core = 3 Gbps
SSL Offload Capacity
cores = full handshakes per second ÷ signing operations per core + bulk throughput ÷ AES throughput per core, where full handshakes = total × (1 − resumption rate).
Effect of session resumption
Resumed handshakes skip the asymmetric operation entirely, so only (1 − resumption rate) of connections consume signing capacity.
Total Cores Required
= 2.76
Full Handshakes per Second
= 2,400
Cores for Asymmetric Handshakes
= 0.10
Cores for Bulk Encryption
= 2.67
CPU Utilisation
= 17.3
Signing Operations per Core
= 25,000 ops/s
How it works
TLS costs are two separate things: one expensive asymmetric operation per new handshake, and cheap symmetric encryption on every byte. Sizing them separately shows which one is actually the constraint, and session resumption removes the asymmetric cost from most connections. Moving from RSA-2048 to ECDSA P-256 cuts the asymmetric cost by more than an order of magnitude, which is often the difference between needing an offload appliance and not.
Formulas
SSL Offload Capacity
cores = full handshakes per second ÷ signing operations per core + bulk throughput ÷ AES throughput per core, where full handshakes = total × (1 − resumption rate).
- opsPerCore
- ≈1500/s for RSA-2048, 240/s for RSA-4096, 25000/s for ECDSA P-256
- bulkCores
- Symmetric AES-GCM work, which scales with bytes not connections
Effect of session resumption
Resumed handshakes skip the asymmetric operation entirely, so only (1 − resumption rate) of connections consume signing capacity.
Frequently Asked Questions
How is SSL Offload Capacity calculated?
cores = full handshakes per second ÷ signing operations per core + bulk throughput ÷ AES throughput per core, where full handshakes = total × (1 − resumption rate). TLS costs are two separate things: one expensive asymmetric operation per new handshake, and cheap symmetric encryption on every byte. Sizing them separately shows which one is actually the constraint, and session resumption removes the asymmetric cost from most connections.
Why does SSL Offload Capacity matter?
Moving from RSA-2048 to ECDSA P-256 cuts the asymmetric cost by more than an order of magnitude, which is often the difference between needing an offload appliance and not.
What values do I need to enter?
This calculator takes 6 inputs: TLS handshakes per second, Certificate key type, Handshakes resumed from a session ticket, CPU cores available for TLS, Encrypted bulk throughput, AES-GCM throughput per core. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
You might also need
- TLS Handshake Rate CalculatorCommonly used together
- Reverse Proxy Throughput CalculatorCommonly used together
- Application Gateway CalculatorCommonly used together
- TLS OverheadCommonly used together
- HAProxy Capacity CalculatorAlso in Load Balancing & ADC
- NGINX Capacity CalculatorAlso in Load Balancing & ADC