Possible causes for request time taking twice as long as upstream response time

Hello,

I am doing some performance analysis for one of our sites.
In the Nginx access_log, I record the $request_time and the
$upstream_response_time.

While looking at these logs I can see that sometimes these numbers have
a fairly large delta.
For example one request’s request_time is 1.553 while the
upstream_response_time is 0.864.

What are some of the potential causes for this large delta and is there
anything I can do about it?

A few reasons I can think of may be:

  • The requester is on a slow internet connection : Not much I can do
    about that

  • Nginx is getting too many requests : Add more workers and or more
    Nginx servers

Thanks,

Zev

On 02/04/2011 07:23 AM, Zev B. wrote:

While looking at these logs I can see that sometimes these numbers have a fairly
large delta.
For example one request’s request_time is 1.553 while the upstream_response_time
is 0.864.

Hello, did you find any more info on this ? I was also doing tuning on
my NGINX setup and I also wondering about this delta.

Regards.


Simone

Hello!

On Wed, Feb 29, 2012 at 10:38:26AM +0100, Simone F. wrote:

On 02/04/2011 07:23 AM, Zev B. wrote:

While looking at these logs I can see that sometimes these numbers have a
fairly large delta.

For example one request’s request_time is 1.553 while the
upstream_response_time is 0.864.

Hello, did you find any more info on this ? I was also doing
tuning on my NGINX setup and I also wondering about this delta.

$request_time is a total time of request processing, including
reading request from a client and sending response to the client.

$upstream_response_time is a time of obtaining response from an
upstream server.

The $request_time variable is expected to be always larger than
$upstream_response_time one as in addition to $upstream_response_time
it also includes at least a) reading request from a client and b)
sending (buffered part of) the response to the client. Both (a)
and (b) may take a while.

Maxim D.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs