$request_time variable = 0 for small files.

J Carter jordanc.carter at outlook.com
Thu Mar 7 09:45:31 UTC 2024


Hello,

On Thu, 7 Mar 2024 08:17:23 +0200
Clima Gabriel <clima.gabrielphoto at gmail.com> wrote:

> Greetings,
> I'm investigating a bug, super easy to reproduce.
> Thought you might be curious.
> 
> Minimal Nginx config. Create two files. 100M and 1M:
> dd if=/dev/zero of=/var/www/file100M bs=100M count=1
> dd if=/dev/zero of=/var/www/file1M bs=1M count=1
> 
> Get them files:
> curl --limit-rate 10M   -o /dev/null 127.0.0.42:80/file100M
> curl --limit-rate 100k  -o /dev/null 127.0.0.42:80/file1M
> 
> Both transfers take ~10s, but Nginx logs 0s request_time for the small file.
> 

This isn't an issue with nginx. The response nginx sends
truly does take 0s to reach the client's socket.

Curl's limit-rate flag only applies at the application layer, but it has
no effect on curl's tcp socket, or it's buffers/how fast things are
read into the buffer. The entire response sent by nginx is being
received into into curl's tcp socket buffer instantly, which is
auto-scaled to a large window size because you are making these
requests from local machine.

You can temporarily set tcp read window to smallest possible minimum,
default, and maximum to confirm. Like this:

sysctl -w net.ipv4.tcp_rmem="4096 4096 4096"

or just view tcp traffic via wireshark.

> master_process off;
> daemon off;
> error_log /dev/stderr;
> events {}
> http
> {
> log_format req_time  "$request_time";
>     server
>     {
>             server_name 127.0.0.42;
>             listen 127.0.0.42:80;
>             root /var/www/;
>             index index.html;
>             location /
>             {
>             access_log /dev/stderr req_time;
>             error_log /dev/stderr;
>             }
>     }
> }


More information about the nginx mailing list