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.
1
-
2It would be nice to see an accepted answer for this.– HyppyJun 14, 2012 at 22:43
Add a comment
|
8 Answers
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.
-
Can we get some specs on the hardware of that machine? encryption is highly dependent on processor power. Jul 22, 2009 at 11:37
-
1I 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.– kovertJul 22, 2009 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.– knweissJul 22, 2009 at 14:54
-
1Your answer has prevented me from posting a question which would have been closed within 20 seconds. Thanks! Dec 12, 2014 at 21:28
-
Can you post the full specs of the SSL config – or use something like mozilla.github.io/server-side-tls/ssl-config-generator? Apr 10, 2015 at 18:37
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.
answered Jul 21, 2009 at 18:53
-
2David 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– radiusJul 21, 2009 at 19:20
-
Aside from the encryption speed, what about the SSL handshake, will that have any impact on server performance and throughput?– erotsppaJul 21, 2009 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. Jul 21, 2009 at 21:09
answered Jul 21, 2009 at 22:04
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.
I second the recommendation for nginx. In my own tests, it has held up well as a dedicated SSL offloader.
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.
I can confirm that the added load for encryption is very small compared to every other element included (scripting, network, ...)
answered Jul 21, 2009 at 21:01
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.
