Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
+1 Thanks for asking it out. :) –  M.N Jul 22 '09 at 10:46
2  
It would be nice to see an accepted answer for this. –  Hyppy Jun 14 '12 at 22:43
add comment

7 Answers

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.

share|improve this answer
2  
David is right, it depend of the kind of content you have. The good way would be to benchmark with apache bench httpd.apache.org/docs/2.2/programs/ab.html –  radius Jul 21 '09 at 19:20
    
Aside from the encryption speed, what about the SSL handshake, will that have any impact on server performance and throughput? –  erotsppa Jul 21 '09 at 19:47
    
The SSL handshake will add a couple of packets to the front of a connection. The impact of this will depend massively on the latency of the connection between the server and client. HTTP keepalives will reduce the impact of this handshaking. –  David Pashley Jul 21 '09 at 21:09
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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

share|improve this answer
add comment

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.
share|improve this answer
1  
+1 Nice job there. Thanks for posting the numbers. –  M.N Jul 22 '09 at 10:47
    
Can we get some specs on the hardware of that machine? encryption is highly dependent on processor power. –  Matt Simmons Jul 22 '09 at 11:37
1  
I recently did a lot of testing on a VPS and the single greatest thing that effected performance was the cipher being used. If you restrict ciphers to 128bits then you should be able to get about 500-600 requests a second. Using a 256bit cipher that will drop to < 100 requests a second. I believe when I did my own testing it was 30 requests a second. Obviously the actual numbers depends on your machine. –  kovert Jul 22 '09 at 13:03
    
Matt Simmons, I used a 2 core 64-bit Ubuntu 9.04 VM (VMware Fusion) running on a early 2008 Mac Pro with 2x Quad-Core 2.8 GHz Intel Xeon CPUs. –  knweiss Jul 22 '09 at 14:54
add comment

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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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