# Nginx & upstream\_response\_time

**URL:** <https://www.ruby-forum.com/t/nginx-upstream-response-time/223392>\
**Category:** NGINX\
**Created:** [October 2, 2012, 3:45pm UTC](https://www.ruby-forum.com/t/nginx-upstream-response-time/223392 "2012-10-02T15:45:27Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![aris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/258eb7/32.png) [@aris](https://www.ruby-forum.com/u/aris)\
**Post date:** [October 2, 2012, 3:45pm UTC](https://www.ruby-forum.com/t/nginx-upstream-response-time/223392/1 "2012-10-02T15:45:27Z")

</div>

Hi,

Currently I’m running nginx 1.2.4 with uwsgi backend. To my  
understanding $upstream\_response\_time should represent time taken  
to deliver content by upsteam (in my case uwsgi backend). It looks like  
it’t not the case for myself.

uwsgi specific snippet:

server {  
…  
uwsgi\_buffering off;  
uwsgi\_buffer\_size 1M;  
uwsgi\_buffers 2 1M;  
uwsgi\_busy\_buffers\_size 1M;

location / {  
uwsgi\_pass unix:/var/run/uwsgi/uwsgi.sock;  
include uwsgi\_params;  
uwsgi\_modifier1 5;  
}  
}

On backend I’m running uWSGI with 1 worker only. Backend app  
(PSGI) generates 900kB output then waits for 10s and finishes response:

my $app = sub {  
my $env = shift;  
return sub {  
my $respond = shift;  
my $writer = $respond-\>([200, [‘Content-Type’, ‘text/html’]]);  
for (1…900) {  
my $dt = localtime;  
$writer-\>write("[$dt]: " . “x” x 1024 . “\n”);  
}  
sleep 10;  
$writer-\>close();  
};  
};

When I use “slow” client connecting to nginx (eg. socat  
TCP:127.0.0.1:80,rcvbuf=128 STDIO) I can see the following hapening:  
Backend server gets busy only for ~10s (this is what I expect). If I  
issue 2 concurrent requests one is served immediately and 2nd one after  
~10s. This behaviour would indicate that backend was able to deliver  
content in ~10s (whole response was buffered as buffer size is big  
enough to accommodate full response and we have only 1 worked at the  
backend). Unfortunately access log disagrees with that as it makes  
$upstream\_response\_time almost equal to $request\_time (eg. ~1000s vs  
~10s of expected). Is this an expected behaviour ?  
Regards,

Marcin

---

<div class="post-metadata">

**Author:** ![marcind](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/cc9497/32.png) [@marcind](https://www.ruby-forum.com/u/marcind)\
**Post date:** [October 2, 2012, 4:30pm UTC](https://www.ruby-forum.com/t/nginx-upstream-response-time/223392/2 "2012-10-02T16:30:29Z")

</div>

Hello!

On Tue, Oct 02, 2012 at 03:44:38PM +0200, Marcin D. wrote:

> …  
> uwsgi\_buffering off;

[…]

> When I use “slow” client connecting to nginx (eg. socat  
> TCP:127.0.0.1:80,rcvbuf=128 STDIO) I can see the following hapening:  
> Backend server gets busy only for ~10s (this is what I expect). If I  
> issue 2 concurrent requests one is served immediately and 2nd one after  
> ~10s. This behaviour would indicate that backend was able to deliver  
> content in ~10s (whole response was buffered as buffer size is big  
> enough to accommodate full response and we have only 1 worked at the  
> backend). Unfortunately access log disagrees with that as it makes  
> $upstream\_response\_time almost equal to $request\_time (eg. ~1000s vs  
> ~10s of expected). Is this an expected behaviour ?

You asked nginx to work in unbuffered mode, and in this mode  
doesn’t pay much attention to what happens with backend connection  
if it isn’t able to write data it already has to a client. In  
particular it won’t detect connection close by the backend (and  
stop counting $upstream\_response\_time).

This is probably could be somewhat enhanced, but if you care about  
$upstream\_response\_time it most likely means you don’t need  
“uwsgi\_buffering off” and vice versa.

–  
Maxim D.

> **[F5 NGINX: Built for cloud-native apps. Ready for AI traffic.](https://www.f5.com/products/nginx)**
>
> Deliver modern applications with NGINX. Explore high-performance load balancing, API gateways, and web server solutions trusted by top global enterprises.

---

<div class="post-metadata">

**Author:** ![marcind](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/cc9497/32.png) [@marcind](https://www.ruby-forum.com/u/marcind)\
**Post date:** [October 2, 2012, 4:59pm UTC](https://www.ruby-forum.com/t/nginx-upstream-response-time/223392/3 "2012-10-02T16:59:42Z")

</div>

Hi Maxim,

On Tue, 2 Oct 2012 18:30:07 +0400  
Maxim D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> You asked nginx to work in unbuffered mode, and in this mode  
> doesn’t pay much attention to what happens with backend connection  
> if it isn’t able to write data it already has to a client. In  
> particular it won’t detect connection close by the backend (and  
> stop counting $upstream\_response\_time).

I see.

> This is probably could be somewhat enhanced, but if you care about  
> $upstream\_response\_time it most likely means you don’t need  
> “uwsgi\_buffering off” and vice versa.

Well, I don’t completely agree. As it was explained at  
[http://forum.nginx.org/read.php?2,193347,193446#msg-193446](http://forum.nginx.org/read.php?2,193347,193446#msg-193446) some sort of  
buffering still takes place even though we work in unbuffered mode. The  
only reason why we went for unbuffered mode is latency.  
Regards,

Marcin