50

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.

erotsppa
  • 2,113
  • 6
  • 23
  • 24

8 Answers8

59

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.
knweiss
  • 4,015
  • 24
  • 20
  • 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
  • 1
    Your answer has prevented me from posting a question which would have been closed within 20 seconds. Thanks! – MonkeyZeus Dec 12 '14 at 21:28
  • Can you post the full specs of the SSL config – or use something like https://mozilla.github.io/server-side-tls/ssl-config-generator/? – Chris Adams Apr 10 '15 at 18:37
10

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.

David Pashley
  • 23,497
  • 2
  • 46
  • 73
  • 2
    David is right, it depend of the kind of content you have. The good way would be to benchmark with apache bench http://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
8

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

SaveTheRbtz
  • 5,691
  • 4
  • 32
  • 45
1

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.

Keith
  • 352
  • 3
  • 11
1

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

Chris
  • 869
  • 1
  • 7
  • 13
0

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.

Coops
  • 6,055
  • 1
  • 34
  • 54
0

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

Francesco Abeni
  • 575
  • 1
  • 4
  • 14
0

From my experience the general rule is directly related to how large your public key is (eg. 2048, vs 4096, vs 8192) all take significantly longer. However I can hardly notice a difference in a Desktop environment, but mobile is where you see a difference since it takes computing power.

In general it is unfortunate but SSL has always and will likely always take a huge performance penalty.

Areeb Soo Yasir
  • 371
  • 3
  • 4