2

I have a problem with a slow Apache server with SSL 256bit cert

ab -n 500 https://example.com/
Time per request 29 ms

ab -n 500 http://example.com/
Time per request 10 ms

52 Bytes is sent in both requests and the tests are done from a server in the same datacenter

conf

SSLEngine on
SSLProtocol All -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite ALL:!ADH:!EXP:!LOW:!RC2:!3DES:!SEED:!RC4:+HIGH:+MEDIUM

Is it normal that SSL is 3 times slower than plain HTTP requests?

Community
  • 1
clarkk
  • 2,035
  • 8
  • 24
  • 36
  • 100ms for dns is not necessarily that slow. It pretty much depend on where your server is located compared to ultratools and shouldn't impact customers much as they probably use a recursive dns server somewhere (unless you are the one providing the dns) – eltrai May 21 '15 at 11:02
  • Ok, but what about the rest 170ms (270ms) in the request? :) – clarkk May 21 '15 at 11:21
  • 3
    Changing to `SSLCipherSuite ALL` is very unlikely to slow anything. It *might* speed the handshake if the client offers unauthenticated suites, but those are usually blacklisted as insecure. What's your ping time client to server? SSL/TLS adds at least two roundtrips (sometimes more) on initial negotiation, and one on resumption. "Pipelining" or "pooling" (multiple requests on one connection) and/or resumption (multiple connections using the same handshake results) may be much faster. – dave_thompson_085 May 23 '15 at 22:29
  • I switched the times.. edited – clarkk May 25 '15 at 21:49
  • 2
    Perhaps you should also benchmark slower pages, if you make pages that always take 100/200/300ms to render, you'll see much clearer in absolute terms how much time the SSL part is costing. A time per request of 10ms is nearly impossible to maintain without an in memory cache. – gnur May 27 '15 at 06:53
  • How does `ab` work? Does it open connection, send request and receive response and close the connection, or does it share the same TLS connection? If this is the case then considering the amount TLS protocol packets exchanged before you have an HTTPS connection established, it does not look "slow" to me. Refer to what @dave_thompson_085 said in more detail to understand why. If we are talking of browsers then they will reuse the connection for multiple requests/responses to the same server, so the TLS protocol overhead is much less. – FooF May 28 '15 at 09:32

5 Answers5

7

How did you benchmark your server? What application is running behind your HTTPS server? What CPU does your server use? How you can see, your question lack many important details...

Anyway, SSL surely is somewhat slower then "pure" HTTP: public key cryptography is way slower then symmetric-key one, and this is the very reason why pubkey is only used to exchange a private, symmetric key and the channel the switches to symmetric key crypto.

shodanshok
  • 47,711
  • 7
  • 111
  • 180
  • Have updated my question.. What do you mean by what application is running behind the HTTPS server? – clarkk May 25 '15 at 19:49
  • I mean: what page/application is serving your https server? It is the same page as the http one? Anyway, as stated above, a difference of about 19-20 ms (as per your testing with apache benchmark), is reasonable. So I think you have no problems here. – shodanshok May 26 '15 at 09:03
  • Its the same page/application behind both http and https.. But if I change `SSLCipherSuite ALL:!ADH:!EXP:!LOW:!RC2:!3DES:!SEED:!RC4:+HIGH:+MEDIUM` to `SSLCipherSuite ALL` there is no difference in request time.. Should the last cipher take longer to request? – clarkk May 26 '15 at 09:50
  • Some chippers are known to be faster (and insecure) because they require less math to be done to calculate the request. Setting it to all makes the server use the fastest method available (explaining why it is faster). But to be safe you should never use the 'SSLCipherSuite ALL' because of security reasons (hearthbeat and POODLE attacks for instance) – noahp78 May 26 '15 at 14:57
  • Setting it to all doesn't make the server use the fastest method available - it allows the server to use all possible methods, including low-security ones (some of which are in fact faster). The client and the server will negotiate which cipher to use. In general clients will probably not choose low-security ciphers. So unless you somehow force a low-security cipher, identical times are no surprise. REGARDLESS, you shouldn't allow ALL (and probably not MEDIUM either). If you want https, you want encryption that is hard to break. check out https://www.ssllabs.com/ for more info. – Dan Pritts May 26 '15 at 16:59
2

HTTPS is slower because it has more data to exchange (the X.509 certificate from the server), it has a secure data connection to set up, ...

ab can give 'Connect' time and that's where you'll see your timing difference. TLS setup take more time than no setup.

Etienne Bagnoud
  • 36
  • 2
2

You need to realise the difference between what ab does and what a browser does. (I'm not going to answer what ab does, because I'm not familiar enough with it).

For example:

  1. Is ab using TLS session re-use? A browser would, and would perform much faster because of it (for subsequent requests). You can verify this with wireshark (perhaps https://ask.wireshark.org/questions/9007/ssl-session-reuse is useful)
  2. Is ab using ciphers that are known to be slow (you can see what cipher gets negotiated in the ssl_request_log)
  3. Are you supporting HTTP keep-alive on the HTTPS connection? You ought to, even just for long enough to pull all the assets on a page. This will really cut down on the number of SSL/TLS requests made to the server.
  4. Do you have cache-friendly content on your site (especially for the browsers cache) -- are you making use of response headers such as Cache-Control: public, max-age=3600, s-max-age=3600.

If you concentrate on those, then you can easily make a HTTPS-only site run nice and quickly. This is what I do for a video-streaming site that is (effectively) HTTPS only, and I have not had to worry about SSL connection times.

Cameron Kerr
  • 4,069
  • 19
  • 25
0

Yes, it is normal for HTTPS to be approximately 3 times slower at establishing connection than HTTP. Here is nice read explaining why.

dtoubelis
  • 4,677
  • 1
  • 29
  • 32
0

Reasons for slow down of website:

  • SSL certificates carry several intermediate certificates that increase data volume during handshake.

  • OCSP and CRL performance is also not corrected as a website takes 1/3 of a second in replying to an OCSP request and establishing a connection.

Recommendations for fast HTTPS connections:

  • The utilization of CPU resources can be mitigated by the compacting of textual content, or upgrade the current process to handle the encryption task.

  • You need to make sure that everything on the page is retrieved over HTTPS.

  • Take help of SPDY - an open source network protocol of Google that minimize the web page loading time.

  • On Certificate authority side, CAs can reduce OCSP and CRL response time from 300ms to 100ms (milliseconds).

  • The CA can reduce the intermediate chain size in SSL certificates as it consumes additional bytes and time.

Jason Parms
  • 272
  • 2
  • 5