request_time much slower than upstream_response_time

[Igor Sysoev]

On Sun, Jun 22, 2008 at 11:36:44AM +0400, Igor Sysoev wrote:

> 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 https://www.oursite.com 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;

-   ssl_session_cache       shared:10m;
+   ssl_session_cache       shared:SSL:10m;


-- 
Igor Sysoev
http://sysoev.ru/en/