Big difference between upstream response time and request time

Maxim Dounin mdounin at mdounin.ru
Thu Oct 16 01:02:35 MSD 2008


Hello!

On Wed, Oct 15, 2008 at 01:26:26PM -0700, Praveen wrote:

> Thanks! What about the upstream response time? I'm assuming that it is
> time from initiating a connection to the backend server till the last
> byte of the response is received.

Yes.  And $upstream_response_time worth monitoring, since increase 
here indicate that something goes wrong with your backends.

Note: $upstream_response_time may contain multiple values, 
separated by ", ".  This may happen if for some reason request 
wasn't processed by first backend server and went to other one 
according to proxy_next_upstream setting.

Maxim Dounin

> 
> -p
> 
> On Wed, Oct 15, 2008 at 11:03 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> > Hello!
> >
> > On Wed, Oct 15, 2008 at 10:25:20AM -0700, Praveen wrote:
> >
> >> Hi,
> >> I'm using nginx as a reverse proxy to my backends. I see there is a
> >> huge discrepancy between upstream response time and request time.
> >>
> >> X.X.X.X [15/Oct/2008:09:32:57 -0700] "GET /js/something.js HTTP/1.1"
> >> upstream_response_time 0.005 request_time 105.026 90732578
> >> 10.3.0.134:8000
> >>
> >> It's generally negligible. But sometimes its as high as 5 or more
> >> seconds, and in some cases as high as the example above.
> >>
> >> Any idea what's happening? nginx is running on a dedicated server, and
> >> has about 2000 active connections.
> >
> > The $request_time variable measures wall clock time it took to
> > fully process request, from first byte got from client to last
> > byte sent to client.  This includes time spent waiting for client
> > and may really vary depending on what client does / quality of
> > client's network connection / etc.
> >
> > Generally you shouldn't pay much attention to this number unless
> > you have control over the client in question.
> >
> > Maxim Dounin
> >
> >
> 
> 
> 
> -- 
> Praveen
> 
> Can you yell "Movie!" in a crowded firestation?
> 
> http://tigertrail.net
> 





More information about the nginx mailing list