How much of a performance hit for https vs http for apache?

Question

Roughly how much of a performance hit will https take compared to http for the same page? Suppose I can handle 1000 requests/s for abc.php, how much will it decrease by when accessed through https? I know this might be dependent on hardware, config, OS etc etc but I am just looking for a general rule of thumb/estimate.

Answer 1

For a quick&dirty test (i.e. no optimization whatsoever!) I enabled the simple Ubuntu apache2 default website (which just says "It works!") with both http and https (self-signed certificate) on a local Ubuntu 9.04 VM and ran the apache benchmark "ab" with 10,000 requests (no concurrency). Client and server were on the same machine/VM:

Results for http ("ab -n 10000 http://ubuntu904/index.html")

• Time taken for tests: 2.664 seconds
• Requests per second: 3753.69 (#/sec)
• Time per request: 0.266ms

Results for https ("ab -n 10000 https://ubuntu904/index.html"):

• Time taken for tests: 107.673 seconds
• Requests per second: 92.87 (#/sec)
• Time per request: 10.767ms

If you take a closer look (e.g. with tcpdump or wireshark) at the tcp/ip communication of a single request you'll see that the http case requires 10 packets between client and server whereas https requires 16: Latency is much higher with https. (More about the importance of latency here)

Adding keep-alive (ab option -k) to the test improves the situation because now all requests share the same connection i.e. the SSL overhead is lower - but https is still measurable slower:

Results for http with keep-alive ("ab -k -n 10000 http://ubuntu904/index.html")

• Time taken for tests: 1.200 seconds
• Requests per second: 8334.86 (#/sec)
• Time per request: 0.120ms

Results for https with keep-alive ("ab -k -n 10000 https://ubuntu904/index.html"):

• Time taken for tests: 2.711 seconds
• Requests per second: 3688.12 (#/sec)
• Time per request: 0.271ms

Conclusion:

• In this simple testcase https is much slower than http.
• It's a good idea to enable https support and benchmark your website to see if you want to pay for the https overhead.
• Use wireshark to get an impression of the SSL overhead.

Answer 2

On modern servers, I'd say your bottleneck would be the network and your application, not the encryption. The TLS/SSL in apache will be written in fairly optimised C, so will be dwarfed by your PHP code, especially if you're going to be doing things like database access. Serving static files will probably have a bigger impact, as the encryption will become a bigger part of the whole process. I can't give you any concrete figures, but I'd be surprised if it was more than 5% and probably nearer a couple of percent.

Answer 3

Don't assume anything, test it yourself! On your specific web apps of course.

• ab
• siege
• JMeter

Answer 4

I find that on modern hardware, I am more likely to be I/O bound for a particular transaction than I am processor (compute) bound. This is particularly true when talking about compression and encryption. 128-bit encryption is trivial these days - I am generally getting hit much harder building and delivering the outgoing pages than I am using SSL, and have not noticed a significant difference in performance between http and https traffic in a a few years.

Answer 5

Of course if the SSL processing does hit hard, you can always move it off-server to a dedicate box. There is a nice write up of doing this with nginx over here. This is something we've done on highly loaded layer 7 load balanced servers.

Answer 6

I can confirm that the added load for encryption is very small compared to every other element included (scripting, network, ...)

Answer 7

I second the recommendation for nginx. In my own tests, it has held up well as a dedicated SSL offloader.