http://www.cs.princeton.edu/~vivek/pubs/pai_flash_99.pdf http://www.cs.princeton.edu/~vivek/pubs/pai_flash_99.pdf That's a reasonably good paper on the trade-o

http://www.cs.princeton.edu/~vivek/pubs/pai_flash_99.pdf http://www.cs.princeton.edu/~vivek/pubs/pai_flash_99.pdf That's a reasonably good paper on the trade-offs between event-driven, multi-threaded, and hybrid approaches to file serving. I don't know that much about nginx in particular, but it seems like they've implemented thread pools for blocking operations: https://www.nginx.com/blog/thread-pools-boost-performance-9x/ https://www.nginx.com/blog/thread-pools-boost-performance-9x.... "Hard drives are slow (especially the spinning ones), and while the other requests waiting in the queue might not need access to the drive, they are forced to wait anyway." So, if you're blocking reading a file from the hard drive, all the other requests are queued up behind it. The thread-pool approach noted in the nginx blog sounds pretty much the same as the approach in the linked paper. nginx does have a good reputation for performance, but I think a lot of that reputation comes as a front-end for web applications rather than serving lots of hard-to-cache files. Anyway, the nginx blog article as well as the academic paper note that single-threaded event-driven has drawbacks around file io and using a worker pool of threads or processes to offload blocking operations onto can help mitigate that.