Size SSL/TLS offload cores separately for asymmetric handshakes and symmetric bulk encryption, including session resumption.
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.
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.
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.
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.
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.