Give statics nginx'om

Starting with version 0.8.11, nginx has a new feature for distributing statics - using AIO (Asyncronous Input-Output - non-blocking I / O) for Linux and FreeBSD.

What is this event significant? Up to this point, nginx used the non-blocking mode only when working with the network - any work with files blocked the workflow. What did it lead to? If you have a lot of different content, which is not all in the OS cache (photohosting, etc) - then sooner or later all 50, 150, 200 processes will wait for disk operations and will not be able to serve the new client - even if the content you need can be given from the file cache or request from the backend.


How to deal with this before?
')

• The first method is to increase the number of workflows. But no matter how many times there are, there is always a chance that everything will be blocked on the disk.
• The second way is to distribute dynamics and statics by different nginxes. But requests for popular statics will not be served as soon as they could.
• Further complicate the 2nd scheme - define the concept of "popular files", and distribute them separately. But the OS cache will always work more efficiently than its own list of popularity (and this, in essence, is a repetition of the logic of the cache operation)

Now there is a new way, using a small number of workflows, to distribute everything in non-blocking mode. Testing will emulate the load on file / image hosting - returning a large number of relatively small files. The disk at the same time rests on the speed of seek seek.

Testing method:

• Test server - FreeBSD OC 7.2 stable, 2xSATA 150GB 7200 rpm raid1, 2gb ram
• Memory size for file cache ~ 1.2gb
• The volume of test files is ~ 2.5 gb, each file occupies 8-16kb, the send buffer in nginx is set to 16kb
• nginx version 0.8.19
• Testing server - network connected, bandwidth ~ 20mbit
• The load was created by the ab utility, to generate a random file name, the fastcgi script was used to render the X-Accel-Redirect

Conclusions: judging by the fact that AIO was able to achieve 300 rps, which significantly exceeds the seek rate for the disks used, the FreeBSD kernel can reorder requests through AIO internally, which gives a significant gain in the absence of a smart raid controller with a large cache. When using the same traditional method - a large number of workflows, if they all go to disk, affect the performance only negatively.

PS: a few comments on the method. The speed of generating random file names is sufficient, adds <0.5 ms to the request (there was no need to measure more precisely, this speed could not be achieved). Perhaps in the tests with aio on a large number of streams, the ceiling of the channel was reached. The time of each test is two minutes.

PPS: AIO's work on Linux has not been tested, results may vary in any direction.