Hello!
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:
http://nginx.org/r/$ssl_session_reused
http://nginx.org/r/$connection_requests
http://nginx.org/r/log_format
> The openssl speed result have been posted on http://pastebin.com/hNeVhJfa
> 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
larger).
> 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
http://nginx.org/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
