{{ guidanceHeadline }}
{{ guidanceSummary }}
Operational checks
- {{ item }}
This model isolates server-side TLS handshake CPU. Validate it against new-session rate, resumption hits, handshake latency, and worker CPU on the actual termination tier.
TLS Handshake Load Calculator
Estimate TLS handshake CPU demand from request rate, connection reuse, full and resumed costs, surge traffic, and the available core budget.{{ summaryTitle }}
{{ summaryValue }}
{{ summaryLine }}
{{ badge.label }}
{{ badge.value }}
{{ primaryCopyAnnouncement }}
Load estimate
{{ row.label }}{{ row.display }}
Calculation method:
One fully occupied CPU core supplies 1,000 CPU milliseconds per second.
{{ formulaEquation }}
{{ row.label }}
{{ row.value }}
{{ row.note }}
| Measure | Value | Decision use | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.display }} | {{ row.detail }} |
Introduction:
HTTPS request rate is not TLS handshake rate. A client can send many requests over one established connection, especially with keep-alive, pooling, or HTTP/2 multiplexing. CPU pressure rises when more requests arrive on fresh connections, so a reconnect storm can be harder on a TLS termination tier than a larger volume of reused traffic.
Every new secure connection performs a handshake before ordinary application data flows. A full handshake carries the heavier authentication and key-establishment work. A resumed handshake uses previously established session material when both sides accept it, usually reducing the cryptographic work. Mutual TLS, certificate chains, key types, protocol versions, and library behavior can change those costs.
- New-connection share
- The percentage of HTTPS requests that create a new TLS connection instead of using an existing one.
- Full-handshake share
- The percentage of new TLS connections that take the full path rather than a resumed path.
- CPU milliseconds
- Processor time consumed by one handshake. One fully busy core supplies 1,000 CPU milliseconds per second.
Capacity planning needs a sustained CPU target below the physical core count. Leaving headroom helps absorb scheduler delays, latency variation, certificate work, cache misses, deploy churn, and failover bursts. An optional reserve reduces the usable target further instead of pretending every assigned core is continuously available for handshake work.
Generic handshake costs are useful only for an early screen. The meaningful inputs come from the actual proxy build, cipher and certificate mix, CPU generation, session-resumption behavior, and traffic path. Benchmark full and resumed connections separately, then compare the modeled result with observed CPU and handshake latency under a representative peak.
How to Use This Tool:
Model one TLS termination tier at a time so request rate, connection behavior, CPU cost, and assigned cores describe the same boundary.
- Enter the sustained HTTPS request rate, then set the New TLS connection share from connection or proxy metrics.
- Set the Full handshake share from session-ticket or session-cache evidence. This percentage applies only to the new TLS rate.
- Choose a planning profile or enter measured CPU milliseconds for full and resumed handshakes. Presets are examples, not standards or guarantees.
- Enter the TLS worker cores and planning CPU target. Add a peak multiplier for reconnect or failover traffic and a CPU reserve when the tier needs extra margin.
- Compare handshake CPU demand with effective target cores, then review utilization, headroom, required cores, and reuse guidance together. Re-benchmark when the proxy, cryptography, hardware, or client mix changes.
Interpreting Results:
Target utilization compares modeled handshake demand with the effective CPU budget after the sustained target and reserve are applied. It is not total host CPU utilization. Other proxy work, application processing, kernel overhead, and unrelated workloads remain outside this model.
- Positive headroom means modeled handshake demand is below the effective target; a CPU gap means it is above.
- Assigned cores required expands demand back through the target and reserve fractions. It may be fractional because it is a planning quantity, not a deployment count.
- A safe request ceiling assumes the same new-connection share, handshake mix, CPU costs, peak multiplier, and core budget. Changing any of them invalidates the ceiling.
Technical Details:
The model first applies the peak multiplier, then sends only the new-connection share through TLS setup. That handshake rate is divided into full and resumed paths. Each path converts handshakes per second and CPU milliseconds per handshake into busy cores.
Formula Core:
Peak requests and new TLS handshakes are:
The full and resumed rates partition H. Dividing CPU milliseconds per second by 1,000 converts the two paths into core demand.
Effective target cores apply both the sustained CPU target and the reserve. Required assigned cores reverse those reductions.
Rule Core:
Capacity and reuse labels use explicit inclusive boundaries.
| Status | Exact rule | Planning meaning |
|---|---|---|
| No CPU budget | Effective target cores ≤ 0 | No capacity comparison is available. |
| Within target | Target utilization < 85% | Modeled demand is below the warning boundary. |
| Headroom tight | Target utilization ≥ 85% and < 110% | Validate reconnect peaks before relying on the remaining margin. |
| Over target | Target utilization ≥ 110% | Modeled handshake demand exceeds the capacity target. |
| Reuse healthy | New connections ≤ 5% and full handshakes ≤ 25% | Both connection reuse and resumption are favorable. |
| Reuse risk | New connections ≥ 25% or full handshakes ≥ 60% | Fresh or full handshakes form a large share of traffic. |
| Reuse mixed | All other valid combinations | Inspect timeouts, pools, tickets, and cache hit rate. |
The model accepts nonnegative request rate and handshake costs, 0% to 100% connection and full-handshake shares, 1% to 100% planning CPU target, 0% to 90% reserve, and a nonnegative peak multiplier. Intermediate values are not rounded; displays use practical decimal formatting.
Limitations:
This is a CPU-budget estimate for handshake work, not a complete TLS or server capacity model.
- It does not model handshake latency distributions, memory, network limits, queueing, kernel work, application traffic, or certificate-service dependencies.
- Full and resumed CPU costs must be measured on representative hardware with the real proxy, protocol, certificate, key type, cipher, and mutual-TLS settings.
- Connection shares can change sharply during failover, deploys, client retries, cache loss, idle-timeout changes, or regional traffic shifts.
Worked Examples:
Reconnect peak above target
A steady 10,000 requests/s with a 1.5× peak becomes 15,000 requests/s. At 25% new connections, that is 3,750 handshakes/s; a 60% full share splits them into 2,250 full and 1,500 resumed handshakes. With costs of 3.2 ms and 0.35 ms, demand is 7.725 cores. Eight assigned cores at a 65% target and 10% reserve provide 4.68 effective cores, so utilization reaches about 165.1% and the estimated requirement is 13.21 assigned cores.
References:
- RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3, RFC Editor, August 2018.
- OpenSSL s_time performance timing documentation, OpenSSL Project.
- How to enable TLS session caching in Nginx, Simplified Guide.