最近我們的下載服務遭遇了c30k，導致nginx的下載服務近乎停滯。原因嘛，很簡單，服務器部署在國外，眾所周知的原因，SL機房的線路不穩，加上不同地區出口速率抖動很厲害，為了加速下載，我們放開了限制，允許用戶使用多線程的下載工具。這樣一來，自然產生了c10k問題。下載文件都不小，每個用戶至少使用4線程，同時下載若干個素材。。。很自然并發鏈接數30k以上。

更受限于手頭money，無法擴容（實際上要有錢也不會跑國外)。因此，必須提高單機并發能力和吞吐量。

我們的下載服務是使用Perl寫的一個Plack應用，典型的PSGI，實現下載驗證，實時防火墻，用戶下載跟蹤等等，無法直接使用靜態文件分發（實際上Perl的性能還是很高效的，部署于Starman，對比PHP的實現，是后者（PHP-FPM)的10倍左右）。

Starman是一個很不錯的PSGI Server，它使用傳統的Prefork模式。即便高效，但Prefork確實無法有效應對c10k，我無法把Starman的worker增大到幾百上千個。在以前的文章曾經提到Evented IO是能夠應付c10k的一個方案。因此，我使用Twiggy換下了Starman。Twiggy是基于AE(AnyEvent)的一個PSGI Server，單進程。在低并發下，單進程的Twiggy的qps是弱于Starman，不過到了高并發，Twiggy的優勢就顯現出來了。在實際部署中，我啟動了多個Twiggy進程，分別監聽獨立的端口，nginx則使用upstream進行負載均衡。 10個Twiggy的吞吐量已經遠遠超過了50個Starman worker。 Twiggy的開銷也不大，因此可以很放心的增加Twiggy的進程。

感謝PSGI的接口規范，從Starman切換到Twiggy，應用程序無需做任何改動。（前提是程序內不能有阻塞io的操作）。

另一個問題是服務器的IO-Wait比較高，畢竟下載這個是IO-Bound的任務。

Nginx支持Linux Native AIO，因此我考慮是否使用AIO能夠大大降低IO-Wait? 性能應該有比較明顯的提升？

網上有一些資料，吹噓的Nginx AIO性能提升，神奇云云。我有點將信將疑，因為都沒有任何的測試數據比較，均是人云亦云。另外，多數配置都是或多或少有問題的。

我使用的CentOS, Nginx AIO要使用，必須是CentOS 5.5以上。因為只有5.5的kernel才有AIO的backport，nginx并沒有使用libaio。

此外，Nginx的AIO本來是為FreeBSD開發，Linux固然可以使用，不過受到了Linux AIO的很多限制。

1. 必須使用Direct IO. 這樣一來，導致無法使用vm的disk cache.

我使用的配置如下：

實際性能如何，AIO一定很快么？ 這點即便是Igor也不確定。

從我們自己的實際效果看，AIO并沒有明顯的性能提升，相反，偶爾會輕微增加了IO-Wait，這是因為無法利用diskcache，而如果文件多數又和directio_alignment有偏差（尤其是斷點續傳的時候，多數文件讀取位置在directio_alignment數據邊界外），這部分的數據必須使用blocking io讀取，又沒有disk cache，增加IO－Wait也可以理解。

最終，結論是，與其使用不那么靠譜的Nginx AIO, 不如多開一些Nginx的worker，重復利用vm disk cache， 當內存100%利用率的時候，nginx的靜態文件分發效率是高于AIO模式的。