mTLS Performance Calculator
Calculate the total latency and CPU cost mutual TLS adds to a service mesh, combining handshake overhead and per-request encryption cost.
Inputs
One-time TLS handshake latency cost for a new connection.
Percent of requests that reuse an existing warm connection instead of triggering a new handshake.
CPU time spent encrypting/decrypting payload per request on an established connection.
Sustained request rate through the mTLS-secured path.
Avg mTLS Latency per Request
0.2300ms
Total mTLS CPU Cost
0.460cores
Amortized Handshake Cost
0.1500ms/request
Per-Request Encryption Cost
0.080ms
New Connections per Second
100.0connections/sec
Step by step
Avg handshake overhead/request: handshake × new-connection rate
3ms × 5%
= 0.1500ms
Avg total latency/request: handshake share + encryption
0.1500 + 0.080
= 0.2300ms
Total CPU cost: (new conns × handshake) + (requests × encryption)
100.0 × 3ms + 2000 × 0.080ms
= 460.0 CPU-ms/sec (0.460 cores)
How it works
mTLS cost has two components: a one-time handshake cost paid only by new connections, and a small per-request encryption cost paid on every request regardless of connection age: avg_latency = handshake_overhead_ms × (1 − reuse_rate) + per_request_encryption_us ÷ 1000. Connection reuse is the dominant lever for amortizing handshake cost — at a 95% reuse rate, only 1 in 20 requests pays the full handshake penalty, while all requests pay the much smaller steady-state encryption cost.
Formula
handshake_overhead_ms = handshakes_per_sec × handshake_duration_ms / connections_reused
- handshakes_per_sec
- New TLS handshakes per second
- handshake_duration_ms
- Duration of one TLS handshake (ms)
- connections_reused
- Connection reuse factor
Frequently Asked Questions
Why does connection reuse rate matter so much for mTLS overhead?
The TLS handshake (asymmetric crypto, certificate exchange) is orders of magnitude more expensive than the symmetric encryption used once a session is established — amortizing that one-time cost across many requests on a reused connection is the single biggest mTLS performance lever.
How much CPU does per-request encryption really cost?
Modern CPUs with AES-NI hardware acceleration can encrypt/decrypt payloads with very low overhead — often tens of microseconds per request for typical payload sizes — making steady-state encryption cost much smaller than handshake cost per new connection.
What causes a low connection reuse rate?
Short-lived connections (e.g. from serverless functions, connection pool churn, or aggressive idle timeouts), high pod churn from frequent scaling/redeployment, and clients that don't implement HTTP keep-alive all reduce reuse rate and increase average mTLS overhead.
Does session resumption help beyond connection pooling?
Yes — TLS session resumption (session tickets/IDs) lets a new connection skip the full handshake even without reusing the underlying TCP connection, which is especially valuable for short-lived but frequent connections between the same peers.
You might also need
- Service Mesh Overhead CalculatorCommonly used together
- Envoy Proxy Capacity CalculatorCommonly used together
- Istio Sidecar CPU CalculatorCommonly used together
- Service Mesh Health Score CalculatorCommonly used together
- Retry Policy CalculatorAlso in Service Mesh & API Gateway
- Canary Deployment CalculatorAlso in Service Mesh & API Gateway