I was testing addition of HTTPS to my small website and since I had configuration that allowed to access my website via HTTP or via HTTPS at some point I decided to benchmark it using ab (e.g. ab -n 1000 -c 5 http://{mywebsite}/{resource} vs ab -n 1000 -c 5 https://{mywebsite}/{resource}). To my surprise I found that every request at every percentile took roughly twice as long for HTTPS.

I'm using pretty cheap box (AWS t2.micro to be specific) where I host my web application (java/jetty) and nginx that does gzip and SSL, so, my first thought was that this should not be true for big websites and I don't have enough CPU power there. Plus network performance is known to be small for those boxes.

Then out of curiosity I tried to run the same ab line against some website that have some content available on both HTTP and HTTPS (such as https://www.aol.com/robots.txt vs http://www.aol.com/robots.txt and https://www.fedex.com/robots.txt vs http://www.fedex.com/robots.txt to name a few). And guess what? I saw the same pattern for them as well - every percentile for HTTPS was approximately twice or thrice as big as corresponding percentile for the same resource served via HTTP.

I thought that my provider is to blame, but I tried to run those ab benchmarks from one of AWS boxes and I saw better latency but still the same pattern: HTTP requests were at least twice as fast as HTTPS for both mine and big names websites above.

I wonder what might be the reason for that? I tried to run ab against localhost (obviously with disabled cert check for HTTPS) and the difference was not that big (I'd say ~10-15%).

I'd be happy to know a little bit more about the nature of that overhead above if someone else saw this. I'm not a networking engineer so I have little to no understanding on whether TLS handshake is the sole contributor to this latency increase.

What else could cause those results?


As multiple people pointed out TLS handshake might be root cause. And it is for the above examples when time for performing request is negligible (such as serving static content).

And I just came across ab option that clearly shows this, it is -k option, that enables connection reuse. With this option turned on the overall cost of HTTPS is way smaller than when connections are not reused.

  • 1
    I think you've been observing the effect of the TLS handshake where the first connection to a TLS site requires a couple of additional round trips to establish the TLS session. – HBruijn Nov 28 '16 at 8:08
  • Yep, it's the extra latency caused by the TLS handshake. HTTP2 negates that by reusing the connection, multiplexing many files down the same connection, even sending the files before the browser knows they're needed. I use Nginx and Let's Encrypt for this. Tutorial photographerstechsupport.com/tutorials/… – Tim Nov 28 '16 at 8:11
  • @HBruijn you're right, handshake is the root cause of the observed behavior. I updated my question with the details. – Alex Nov 29 '16 at 4:32

There will be some level of overhead due to encryption, it depends on:

  • Hardware
  • Server
  • Ratio of dynamic vs static content
  • Distance of the Client
  • Session Length
  • Caching

Servers that are having heavy dynamic content tend to impact less by HTTPS because the time spent encrypting (SSL-overhead) is insignificant compared to content generation time. Servers that are heavy on serving a fairly small set of static pages that can easily be cached in memory suffer from a much higher overhead by reducing the throughput. SSL handshaking is the major cost of HTTPS. That is the reason why "Session Length" and "Caching" are important. Longer sessions will mean the handshaking cost will be incurred at the start of the session, but subsequent requests will have relatively low overhead.

Caching can be done at several steps, anywhere from a large-scale proxy server down to the individual browser cache. Generally HTTPS content will not be cached in a shared cache. Many browsers cache HTTPS content for the current session and often times across sessions. The impact the not-caching or less caching means clients will retrieve the same content more frequently. This results in more requests and bandwidth to service the same number of users.

Making lots of short requests over HTTPS will be a bit slower than HTTP, but if you transfer bulk amount of data in a single request, the difference will be insignificant. However, keepalive is the default behaviour in HTTP/1.1, it will do a single handshake and then lot of requests over the same connection can be processed. This makes a significant difference for HTTPS.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.