Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have recently purchased a QuickSSL certificate from GeoTrust, and I am using it on NGINX. Everything is fine, but there is a nasty second before the page actually loads.

If I look at other SSL websites, most of them load instantly like it should.

This is my SSL configuration:

ssl on;
ssl_certificate /usr/local/nginx/ssl/www.crt;
ssl_certificate_key /usr/local/nginx/ssl/www.key;

I found about adding ssl at the end of the listen directive, but it has not solved it.
For this problem to reproduce I have to close the website and revisit it later (about 15 minutes?).

share|improve this question
up vote 3 down vote accepted

SSL handshake is a slow, 3 packet event. That means initial connection will take longer than non-SSL connection - usually 3-4 times longer. Following requests will use SSL session from 1st connection and will be faster, but only as long as the session stays alive.

You can control lifetime of SSL session in NGINX by setting ssl_session_cache and ssl_session_timeout.

Edit: just noticed I have explained why it happens, but not what you can do about it. The answer is sadly very little. How long the initial handshake takes depends on 2 factors: time taken by the actual SSL cryptography (negligible with current hardware) and time taken by the 3 packet exchange which depends only on the network - unless you can get "lower ping" to the server nothing will change.

share|improve this answer
Just wanted to confirm that my API's are indeed 3x slower when using HTTPS. ssl_session_cache and ssl_session_timeout didn't improve the time any in my ApacheBench tests. Thanks for the response, though. – Mauvis Ledford Sep 13 '12 at 23:28
With ApacheBench each and every connection is separate - there is no ssl session reuse: each AB request is exactly like the first request and that's why you see no gain with caching. ssl_session_cache only improves performance on 2nd and further requests within ssl_session_timeout. – c2h5oh Sep 14 '12 at 0:36
Thanks for the reply. I did ab -k -n 25 -c 5 https://url as a small test with ssl_session_cache. I believe this means each of the 5 concurrent connections make five back to back requests. -k flag means "enable the HTTP KeepAlive feature, i.e., perform multiple requests within one HTTP session. Default is no KeepAlive." Perhaps my test was too small but I didn't see a difference, in both cases I'm getting a total median time of 3 seconds. – Mauvis Ledford Sep 14 '12 at 1:05
Nope, I'm fairly sure SSL session persistence isn't maintened by AB. I mean even man mentions that it barely supports secure connections "-s When compiled in (ab -h will show you) use the SSL protected https rather than the http protocol. This feature is experimental and very rudimentary. You probably do not want to use it." Use httperf instead to get real results. – c2h5oh Sep 14 '12 at 1:34
Thanks for the tip, c2h5ch. Have an upvote! – Mauvis Ledford Sep 14 '12 at 5:25

That sounds an awful lot like you've got SSL session caching turned on (the 15 minute wait to make the problem reappear), and either a really slow CPU or horribly latent network path between you and the server, which is causing the problem.

share|improve this answer

Your Answer


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.