SSL slow on nginx

Maxim Dounin mdounin at
Tue Jul 1 13:50:26 UTC 2014


On Tue, Jul 01, 2014 at 03:10:07AM -0400, khav wrote:

> Thanks Maxim and GreenGecko for the insights
> The worker process does match my number of cpu cores (running on 8 cores
> atm)

Good.  It may be also good idea to make sure you don't have 
multi_accept enabled, just in case.

> How can i know  the number of handshakes per seconds occurring on the
> server

First of all, count the number of connections per second (and 
requests per second) - it should be trivial, and may be extracted 
even with nginx stub_status module.  I would generally recommend 
using logs though.  With logs, you should be also able to count 
number of uncached handshakes - by using $ssl_session_reused 
variable and the $connection_requests one.

See here:$ssl_session_reused$connection_requests

> The openssl speed result have been posted on
> for readability

So, basically, your server is able to do about 800 plain RSA 
handshakes per second per core, 6400 handshakes total.

But as previously noted, things can be very much worse with DH 
ciphers, especially if you are using 2048 bit dhparams (or 

> If you can suggest "faster ciphers" with same level of compatibility , i
> would be awesome

It may be good idea to disable DH regardless of the level of 
compatibility.  It's just too slow.

> Will a faster cpu actually solve the issue ?
> My cpu load never reached a value > 0.50 as far as i know and average is
> like 0.30

You mean - 50% CPU usage across all CPUs?  That's looks high 
enough, though not critical.  But it may be a good idea to look 
into per-CPU stats, as well as per process CPU usage.

Note well, CPU is a bottleneck I assumed based on few external 
tests.  It may not be a CPU, but, e.g., a packet loss somewhere.  
And, as I already said, numbers shown by Pingdom are close to 
theoretical minimum, and I don't think there is much room for 
improvement.  The one extra RTT probably deserves investigation, 
but I can't say it's an "issue" - it might be even legitimate.

Maxim Dounin

More information about the nginx mailing list