Thx, Maxim!
Closed.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?2,257510,278936#msg-278936
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Hi Maxim,
Thank you for prompt reply.
I suspect there would be no delays/timeouts if there was a single thread in
nginx that communicates with the upstream server.
There is no simple way to restrict nginx threads number to one in Windows?
Serving static files directly by nginx will likely solve
This needs to stop
On Monday, March 5, 2018, Nagy, Attila wrote:
> On 03/05/2018 12:54 PM, Reinis Rozitis wrote:
>
>> Jesus, why? You start the fsync in a thread and you wait for it to be
>>> completed
>>> with the HTTP response. Until this happens, the main thread can service
>>> other
>>> requ
On 03/05/2018 12:54 PM, Reinis Rozitis wrote:
Jesus, why? You start the fsync in a thread and you wait for it to be completed
with the HTTP response. Until this happens, the main thread can service other
requests.
Have you ever seen an async program which uses threads to run blocking
operations?
On 05-03-18 12:54, Reinis Rozitis wrote:
Have you ever seen an async program which uses threads to run blocking
operations?
The point was that it's odd that you are going to "trust" the userland daemon to finish the sync
operation (which obviously has the possibility to fail) in some backgroun
> Jesus, why? You start the fsync in a thread and you wait for it to be
> completed
> with the HTTP response. Until this happens, the main thread can service other
> requests.
> Have you ever seen an async program which uses threads to run blocking
> operations?
The point was that it's odd that y
On 03/04/2018 12:45 PM, Reinis Rozitis wrote:
That's what really kills performance, because of the async nature of
nginx. That's why I'm proposing an option to do the fsync at the end of
the PUT (or maybe even the whole operation) in a thread(pool).
Then again this way you make it again "asynchr
