Monitors SSL/TLS handshake performance, connection times, and throughput metrics. Tracks performance degradation over time and identifies bottlenecks.
How to Use
1Enter your domain name and optional port
2Click "Measure Performance" to test connection
3Review DNS, TCP, and TLS handshake metrics
Use Cases
•Baseline performance measurement for your servers
•Detect performance regressions after changes
•Capacity planning and infrastructure optimization
Frequently Asked Questions
The monitor tracks DNS resolution time, TCP connection time, TLS handshake time, total connection time, and the negotiated TLS version. Each metric is color-coded for quick assessment.
Regularly enough to establish a baseline, then continuously if you care. A single reading tells you almost nothing, because connection timing depends on where the measurement is taken from as much as on the server. Run it from several locations over a period so that normal variation is visible, and then treat a departure from that baseline as the signal worth investigating. Re-measure after any infrastructure change, because edge moves and load balancer changes alter timings without touching the origin at all.
Common causes include slow DNS resolution, network latency, server load, weak cipher suites, and TLS version negotiation. Use the Handshake Debug tool for detailed analysis.
It depends on distance and temperature. For nearby hosts on warm resolvers the TLS handshake dominates, since DNS and TCP complete in milliseconds. For distant hosts TCP connect time grows with round trips and can exceed the handshake. For cold DNS — first lookup, slow resolver — resolution alone can dwarf both. The breakdown exists precisely because the answer varies; optimize whichever stage your numbers indict.
Because all three stages are timed from the same single connection made for your request, with each timer starting where the previous stopped. There is no sampling, averaging or stored history involved. That also means consecutive runs differ: network jitter moves each stage by milliseconds, so compare runs as ranges rather than exact figures.
Which protocol and suite the handshake negotiated with this probe — the same two facts the handshake-timeline and cipher pages examine in depth. A version below 1.2 or a weak cipher here deserves follow-up on those dedicated pages. The timing page records them as context for the TLS stage, since an older version doing a full two-round-trip handshake partly explains a slow TLS number.
The connection failed before any stage completed, so there was nothing to time and the page says so. The error names the cause — DNS failure, refused connection, timeout — and each points somewhere different: DNS at your resolver, refused at the server or its firewall, timeout at the path between. Fix the connectivity first; performance questions only make sense once connections succeed.
For coarse before-and-after comparisons, yes, with one caution: measure several times on each side. Single runs are noisy because each stage varies with network conditions, so a 20-millisecond improvement in one run proves nothing while a consistent shift across ten runs proves a lot. Keep the vantage point constant too — this probe runs from one location, and distance dominates absolute numbers.
How the Timing Works
Enter a host and this page performs the connection itself in three timed stages, so the total breaks down into where the milliseconds actually go. Every number is measured from a live connection made at request time — there are no estimates and no stored baselines.
1Resolve the hostname and time the lookup. Slow DNS is invisible in most monitoring because it happens before any TCP timer starts, yet on a cold resolver it can dominate the total — this stage makes it visible separately.
2Open the TCP connection and time the connect. This stage reflects network distance and routing: same-region hosts land in single-digit milliseconds while intercontinental paths cost what physics demands, and no TLS tuning can move it.
3Perform the TLS handshake and time it, recording the negotiated version and cipher alongside. This is the stage your configuration controls — TLS 1.3 with session resumption is roughly one round trip, while older versions doing full handshakes cost two.
The reported total is the sum of the three stages, so the parts always account for the whole. A host that cannot be reached returns zeros with the connection error named, rather than invented timings — a failed measurement reported honestly beats a plausible-looking fabrication.
Tips & Best Practices
•Set up continuous performance monitoring for critical TLS endpoints
•Configure performance alerts for degraded TLS performance
•Track performance trends over time to identify degradation
•Use performance data to capacity plan and optimize infrastructure
Technical Details
Monitoring: Real-time TLS performance monitoring Metrics: Handshake time, throughput, and error rates Alerting: Configurable performance threshold alerts Output: Performance dashboard with historical trends
