Nginx的c30k问题解决方法

最近我们的下载服务遭遇了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.
2. 文件只有大小和directio_alignment定义block size整数倍的数据才可以使用AIO，当文件整数据块之前和之后，那些不能取整的部分则是blocking方式读取的，这也是为什么需要output-buffer。directio_alignment大小取决于你使用的文件系统，默认是512,而对于XFS，注意，如果你没有修改XFS bsize, 需要调整为XFS默认的4k.