Using asynchronous, event-driven architecture serves Nginx well as it allows to save up on the precious RAM and CPU context switches while processing thousands and millions of slow clients in separate connections. Unfortunately, event loops, such as the one that power Nginx, easily fail when facing blocking operations. Nginx was born on FreeBSD, which has several advantages over Linux, and one of the relevant ones is a robust, asynchronous input/output implementation. Basically, the OS kernel is able to not block on traditionally blocking operations like reading data from disks by having its own kernel-level background threads. Linux, on the other hand, requires more work from the application side, and very recently, in version 1.7.11, the Nginx team released its own thread pools feature to work better on Linux. You may find a good introduction into the problem and the solution in this official Nginx blog post at https://www.nginx.com/blog/thread-pools-boost-performance-9x/. We will provide an example of the configuration you may use to turn on thread pools on your web server. Remember that you will only need this on Linux.

To turn on background threads that will perform blocking input/output operations without stalling the main loop you use the directive aio in this way:

server {
    location /file {
        root /mnt/huge-static-storage;
        aio threads;
    }
}

You may know the aio directive that is used to turn on the Async IO interface, so it is a natural fit for its use to be extended this way.

The implementation is rather simple to explain from a very high level. Transparently to you, Nginx will run a number (pool) of background, userland-level threads that fulfill the input/output tasks. Nginx will continue to run the main event loop in parallel to waiting for the slow disk or the network.