On 8/2/21 4:04 PM, Maxim Dounin wrote:
> Hello!
>
> On Mon, Aug 02, 2021 at 02:46:03PM +0200, Pierre Couderc wrote:
>
>> On 8/2/21 1:19 AM, Maxim Dounin wrote:
>>> Hello!
>>>
>>> On Sun, Aug 01, 2021 at 10:38:48PM +0200, Pierre Couderc wrote:
>>>
>>>> On 8/1/21 3:32 AM, Maxim Dounin wrote:
>>>>> Hello!
>>>>>
>>>>> On Fri, Jul 30, 2021 at 10:40:00AM +0200, Pierre Couderc wrote:
>>>>>
>>>>>> I am trying to download a 12M pdf file and it takes more than 4 minutes
>>>>>> with http nginx while it takes a few seconds with scp.
>>>>>>
>>>>>> I have asked detailed log here https://paste.debian.net/1206029/
>>>>>>
>>>>>> I see timeouts but I am not able to interpret them correctly.
>>>>>>
>>>>>> nginx is in lxd container in a nearly not used  server (htop load
>>>>>> average 0.08 ...).
>>>>>>
>>>>>> I use nearly defaut debian configuration of nginx.
>>>>> The logs provided suggest that the client is limiting download
>>>>> rather than nginx. Further, the client seems to do at least 17
>>>>> various range requests to the file which is being downloaded, thus
>>>>> downloading many more than the file itself, but this is probably
>>>>> not the issue. Rather, the issue seems that the client does not
>>>>> proceed with the file download while doing these requests.
>>>>>
>>>>> Try disabling Firefox PDF Viewer to see if it helps (Preferences
>>>>> -> General -> Applications -> Portable Document Format (PDF), set
>>>>> to "Save File", see [1]). Alternatively, try using curl (or wget,
>>>>> or fetch, or whatever you prefer) to download the file instead of
>>>>> trying to view it in the browser.
>>>>>
>>>>> [1] https://support.mozilla.org/en-US/kb/view-pdf-files-firefox-or-choose-another-viewer#w_disable-the-built-in-pdf-viewer-and-use-another-viewer
>>>>>
>>>> Thank you very much, I had not the idea it could be a client such as
>>>> firefox, which I suppose bulletproof...
>>>>
>>>> So I followed your idea and tried with wget : about  2 minutes 40s..
>>>>
>>>> This is too much long too as with scp (in wifi at 2meters from the
>>>> server) it is only 3 seconds... ;)
>>>>
>>>> Log is here (shorter ;) : https://paste.debian.net/1206278/
>>> No additional range requests now, though still looks limited by
>>> the client. Any antivirus/firewall on the client (or on the
>>> server)?
>> No. I have not soon understood the interest of a firewall : either the
>> port is closed and  I do not see the interest, either it is open and I
>> can only trust the application which manages it...
>>
>> All my clients are debian and have no antivirus or firewall and tests
>> are done in the room where is the server.
>>
>> nginx is in a lxd container with snap.
> Ok, so it does not seem to be the client issue, yet for some
> reason nginx cannot proceed with sending data to the client as if
> network speed was severely limited.
>
> Is sshd you test against in the same lxd container? Any resource
> limits applied to the container? What happens when you run nginx
> on the host system instead?

Thank you, you put me on new ways, I have many things to check

1- network problems : check if packets are routed through local router

2- if yes, local router has Qos (for SIP phones): : check how it works

In fact it seems that before nginx, I may have to debug network problems...

> [...]
>
>> Time out seem to occur :
>>
>> 2021/08/02 14:39:10 [debug] 17204#17204: *22637 event timer add: 26:
>> 60000:7599423246
>> 2021/08/02 14:39:15 [debug] 17204#17204: *22637 http run request: "/ggg?"
> These aren't timeouts, but debug log lines: first says that nginx
> armed a timer for 60 seconds, and second one is about starting
> request processing 5 seconds later. Debug logging is not
> configured at the global level and hence there is no debug logs
> about event processing, but it is nevertheless clear that the
> request processing was started due to an event reported by epoll()
> rather than due to a timeout.
>
Thank you very much !

PC

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx