request_time much slower than upstream_response_time

Igor Sysoev is at
Sun Jun 22 11:36:44 MSD 2008

On Sat, Jun 21, 2008 at 06:36:15PM -0700, Rt Ibmer wrote:

> Some quick additional information I wanted to add on this issue:
> - As I continue to research this more I am seeing even greater disparities than I originally reported.  For instance in some cases the upstream response was just 0.011 sec while the request_time was a whopping 1.4 sec.
> - This more I look at this the more the problem seems specific to SSL connections. I am using a wildcard cert in case that should make any difference.  Just a guess but maybe there is a blocking condition like only one SSL connection can be negotiated at a time across all incoming requests?  I'm only handling an average of 3 req/sec so its hard to imagine the load itself is playing a factor, but perhaps some concurrent issue here?
> - In my last message I noted the times like 0.015 ms - I did not mean ms those times are actually in seconds (from the nginx log) not ms.
> - As a side note, we are not really passing sensitive information that has to be protected by high end SSL.  However since we are called from within our user's web sites that use SSL, we must answer in SSL if called with because otherwise they would get a mixed content security warning. But if there is a faster ssl algorithm we just need something quick and dirty to make it a valid ssl connection. 

I suspect two causes of the tardiness:

1) It may be caused by SSL handshake: there is 4 packets exchange, and while
   3 packets TCP handshake is not accounted in $request_time, the SSL
   handshake is accounted.

2) It may be caused by SSL builtin session cache cleanups. Try to use
   shared only cache (even if you use the single worker):

-   ssl_session_cache       builtin:20480;
+   ssl_session_cache       shared:10m;

Igor Sysoev

More information about the nginx mailing list