HTTPS connection keep alive performance

Question

Does anyone know what’s the difference, in milliseconds and percentage, between the total time it takes to make an HTTPS request that is allowed to use keep alive vs one that doesn’t? For the sake of this question, let’s assume a web server that has one GET endpoint called /time that simply returns the server’s local time, and that clients call this endpoint on average once a minute.

My guess is that, putting the server on my home LAN, and calling /time from my laptop on the LAN would take 200ms. With keep-alive it’s probably going to be 150ms. So that’s 50ms difference, and 25% improvement.

My second question is similar, but only considers server processing time. Let’s say the server takes 100ms to process a GET /time request, but only 50ms to process the same with keep-alive. That’s 50ms faster, but a 50% performance gain, which is very meaningful as it increases the server’s capacity.

Answer 1

Here is my experiment. It's not HTTP, but it illustrates well the benefits of keeping the connection alive.

My setup is a network of servers that create their own secure connections. I wrote a stress test that creates 100 threads on Server1. Each thread opens a TCP connection and establishes a secure channel with Server2. The thread on server2 sends the numbers 1..1000, and the thread on Server1 simply reads them, and sends "OK" to Server2. The TCP connections and secure channels are "kept alive".

First run:

• 100 threads are created on Server1
• 100 TCP connections are established between Server1 and Server2
• 100 threads are created on Server2 (to serve the Server1 requests)
• 100 secure channels are established, one per thread

total runtime : 10 seconds

Second run:

• 100 threads are created on Server1 (but those might have been reused by the JVM from the previous runs)
• No new TCP connections are needed. The old ones are reused.
• No threads are created on Server2. They are still waiting for requests.
• No secure channels are established

total runtime : 1 second