Thread Pools in Nginx Boost Performance 9x (2015)
1–10 of 62 posts
Re: Thread Pools in Nginx Boost Performance 9x (2015)
#2It would be interesting to compare this with coroutines/fibers, and it would also be interesting to know how latency is affected. In my experience, thread pools introduce latency.
Re: Thread Pools in Nginx Boost Performance 9x (2015)
#3It would be interesting to compare this with coroutines/fibers, and it would also be interesting to know how latency is affected. In my experience, thread pools introduce latency.
> In my experience, thread pools introduce latency.
The headline uses a the word "performance" which is rather ambiguous.
Performance has many aspects: Latency, through-put, resource-usage (doing more with less), etc etc.
A more specific headline wouldn't hurt.
Re: Thread Pools in Nginx Boost Performance 9x (2015)
#4It seems quite similar to libuv's work queue [1]
Re: Thread Pools in Nginx Boost Performance 9x (2015)
#5It would be interesting to compare this with coroutines/fibers, and it would also be interesting to know how latency is affected. In my experience, thread pools introduce latency.
> In my experience, thread pools introduce latency. The headline uses a the word "performance" which is rather ambiguous. Performance has many aspects: Latency, through-put, resource-usage (doing more with less), etc etc. A more specific headline wouldn't hurt.
In the benchmarks reported in the article, both through-put and latency were significantly improved by the new thread pool system.
Re: Thread Pools in Nginx Boost Performance 9x (2015)
#6It would be interesting to compare this with coroutines/fibers, and it would also be interesting to know how latency is affected. In my experience, thread pools introduce latency.
> In my experience, thread pools introduce latency. The headline uses a the word "performance" which is rather ambiguous. Performance has many aspects: Latency, through-put, resource-usage (doing more with less), etc etc. A more specific headline wouldn't hurt.
Being specific about the area being improved (blocking operations with the example of file reads) could be nice.
Re: Thread Pools in Nginx Boost Performance 9x (2015)
#7It would be interesting to compare this with coroutines/fibers, and it would also be interesting to know how latency is affected. In my experience, thread pools introduce latency.
Trick is that nginx uses thread pools for non-blocking reading on the "fast" devices - you can't use coroutines/fibers, because on Linux is not reliably possible to read the regular file in a non-blocking way, as far as I'm aware, so that means that `read` in a single fiber would block entire thread until the data is fetched from the disk.
In the storage engine I'm developing/maintaining, I've been using fibers, for both network and disk IO, until people started noticing that, if number of the client grows, and if they ask a lot of data (generating a lot of disk traffic), the performance drops severely. I've moved to the thread pools, dispatching my disk IO operations there (although it's much problematic for the reads, as writes would be performed by kernel anyway, `fsync` and `close` would be operations that you still want to do in the separate thread): https://github.com/sociomantic-tsunami/dlsnode/blob/master/s...
edit: used right link for the freshly opensourced repo.
Re: Thread Pools in Nginx Boost Performance 9x (2015)
#8Interesting read, however a 2015 tag would be nice,
since the post is from June 19, 2015
Re: Thread Pools in Nginx Boost Performance 9x (2015)
#9this approach sounds very similar to SEDA (staged event driven architecture) that was done a while back, iirc, circa 2001.
Re: Thread Pools in Nginx Boost Performance 9x (2015)
#10It would be interesting to compare this with coroutines/fibers, and it would also be interesting to know how latency is affected. In my experience, thread pools introduce latency.
Fibers and thread pools are not exclusive - you can schedule fibers onto threads. Nginx already uses event-based state-machine approach so context switch is even cheaper than with fibers (at the price of ugly code).
What they talk about in the article is that they offload potentially blocking operations to thread pools. That's not about networking, which is already done asynchronously, but about e.g. reading from a file not present in the page cache. Note that detecting that the needed bytes are already in the page cache and thus the read wouldn't block and should not be offloaded is tricky. As far as I can see they haven't done that yet so this new feature (edit: not so new, the post is from 2015) is not without downsides.