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?

6
  • 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, 2015 at 11:02
  • Ok, but what about the rest 170ms (270ms) in the request? :)
    – clarkk
    May 21, 2015 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. May 23, 2015 at 22:29
  • I switched the times.. edited
    – clarkk
    May 25, 2015 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, 2015 at 6:53

5 Answers 5

7
+50

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.

5
  • Have updated my question.. What do you mean by what application is running behind the HTTPS server?
    – clarkk
    May 25, 2015 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, 2015 at 9: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, 2015 at 9: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, 2015 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 ssllabs.com for more info.
    – Dan Pritts
    May 26, 2015 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.

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.

0

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

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .