3 ms·
100ms for setting up an initial TLS connection is about what I'd expect. It depends on the key size, ciphers, etc, but up to 300ms is typical. However, this sh
by danpalmer 6y ago
100ms for setting up an initial TLS connection is about what I'd expect. It depends on the key size, ciphers, etc, but up to 300ms is typical.
However, this should only be done at the beginning of the connection. After this the client will have a symmetric encryption key that is much faster to use. Their load balancer should be caching these sessions so that subsequent connections don't need to re-negotiate a session key.
If this 110ms is only on the first request, and a cache miss on the sessions, then I'd say that's probably something you should be expecting. If it's after the TLS session has been set up, or on a cache hit, that sounds bad. It also could be that their session cache isn't large enough and is forgetting sessions too soon, causing more TLS negotiation than may be necessary.
- axismundi 6y agoThis is happening for every single request.
- jeromegn 6y agoTheir server and/or your client might not be setup for session reuse. Definitely a thing to check.
- axismundi 6y agoThank you. I will make sure this is enabled.
- dharmab 6y agoMake sure you’re reusing connections. A lot of languages and libraries create a new connection for every request unless you explicitly manage a session or connection pool.
- axaxs 6y agoAlso, make sure the adc is reusing connections. It's a setting on the vserver.
- Matthias247 6y agoMost of the latency of a TLS handshake (which equals the minimum latency for the first response on a HTTPS connection) comes from round trips. You need 1 for TCP connection establishment. And 1 to 2 (depending on the TLS version) for the TLS handshake. 300ms would be rather on the high side. RTTs with todays infrastructure are often 30-50ms if you hit an Edge server (opposed to a server around the world). So you should end up up at around 100ms for the complete TLS connection establishment.