nginx buffers output by default. can you try
proxy_request_buffering off; proxy_buffering off; ? ср, 26 авг. 2020 г. в 16:02, Tim Düsterhus, WoltLab GmbH < [email protected]>: > Hi List, > > please keep this email in Cc for all responses, I am not subscribed to > the list. > > We are running HAProxy 2.1.8 in front of nginx serving static files and > acting as a FastCGI gateway. HAProxy is communicating with nginx using > HTTP/2. Clients are regular web browsers, mostly using HTTP/2. > > Within the HAProxy logs we're sometimes seeing largish 'Tr' values for > static file requests. For example 734ms for the example request below. > The corresponding request in the nginx log shows a $request_time of > 0.000s > (http://nginx.org/en/docs/http/ngx_http_log_module.html#var_request_time). > > HAProxy log line for a static GIF file: > > > Aug 26 10:23:27 *snip* haproxy[3066]: *snip*:1167 > [26/Aug/2020:10:23:26.028] https~ *snip*/nginx 0/0/0/734/1719 200 6540 - - > ---- 19/19/12/12/0 0/0 {*snip*|*snip*} {*snip*|} "GET *snip*.gif HTTP/2.0" > *snip*:59348 5F46381E00F5 > > Some notes regarding the log format: This is the standard HTTP log > format with '%bi:%bp %ID' appended. > > According to the '%bp' value this was not the first request within the > backend connection. The backend connection was established 5 seconds > earlier for a HTTP/1.1 request going to PHP. According to the request ID > this was the 160th (00A0) request after a reload (I just recently added > the logging of %bp). > > > Aug 26 10:23:21 *snip* haproxy[3066]: *snip*:11594 > [26/Aug/2020:10:23:21.148] https~ *snip*/nginx 0/0/2/69/72 200 27432 - - > ---- 19/19/0/0/0 0/0 {*snip*|*snip*} {*snip*|} "GET *snip* HTTP/1.1" > *snip*:59348 5F46381900A0 > > The two requests in nginx' log: > > > Aug 26 10:23:21 *snip* abd21141cdb4[5615]: 5F46381900A0 "GET *snip* > HTTP/2.0" 200 27049 0.070 > > Aug 26 10:23:26 *snip* abd21141cdb4[5615]: 5F46381E00F5 "GET *snip*.gif > HTTP/2.0" 200 6341 0.000 > > Note how the timing for the PHP request matches up what HAProxy was > seeing: Roughly 70ms / 0.070s. The timing for the GIF request is *way* > off, though. > > Any idea what is happening there? It's not really reproducible in any > way. I'll be happy to add more stuff to my logs if that would help. I > can also provide specific configuration settings on request. > > Best regards > Tim Düsterhus > Developer WoltLab GmbH > > -- > > WoltLab GmbH > Nedlitzer Str. 27B > 14469 Potsdam > > Tel.: +49 331 96784338 > > [email protected] > www.woltlab.com > > Managing director: > Marcel Werk > > AG Potsdam HRB 26795 P > >
