和Lighttpd搏斗的一天

原贴：http://blog.scaner.i.thu.cn/index.php/2006/11/17/live-with-lighttpd-2006-11-16/

和Lighttpd搏斗的一天 November 17, 2006

Posted by scaner in : Coding, Linux, Web , trackback

昨天的事情。随便记录一下

具体情况是这样的，完全静态内容，1.4M左右的小文件，每个文件3k-8k(基本上是小图片文件)。每秒完成请求在1000个左右。这个时候，由于disk io的压力，会直接导致Lighttpd整个被block住，包括网络部分。

首先的救急解决方案，别的不废话，Lighttpd同时开上四个，前面堆一个Haproxy，暂时先抗着。虽然还是不怎么样，至少不会全死了，说得过去，继续折腾。

这两天Lighty的作者非常的积极，1.5-pre2发布出来了，还专门在Blog上 讨论了Linux AIO这个现代科技。不管怎么说，光是看着统一的mod_cache核结构，也很值得期待的试一下。弄回来build一run，虽然使用了linux- aio-sendfile做network backend，一样的死菜。察看了一下代码……，可能是考虑效率方面的问题吧，所有小于一个标准page size(x86上就是4K啦)的内容，都是直接sendfile了，没有经过aio这步。咬咬牙，改了程序，拼死aio，不管多大的内容，都用aio的 过程操作。初步的测试表现，都挺好，不过一上压力，又挂了……问题出在Lighttpd 1.5缺省只有64个aio控制块，也就是说最多积压64个io任务，在多就又变成directly sendfile了。这64个对于每秒上百的请求根本没啥作用。继续修改程序，把64修改成128,256,512，都还是会有任务队列冲满的情况。拼死 加到2048个，确实冲满是不发生了，不过io block情况照旧的恶劣，唯一的好处，就是connection还是能正常地accept，请求的处理，该堵的堵，该慢的慢，没有在多变化了。基本上结 论就是，lighttpd aio，对于非常多的非常小文件服务，基本上是没有什么帮助了，除了能保证不因为disk io导致network io的block。不过这个保证也是没有什么用的，如果没有强劲的disk io支持，没有数据往外吐，network io还是要停下来的。而且aio需要以O_DIRECT方式打开文件，貌似会导致系统的buffer不缓存文件，进一步加重disk负载，反而是负面影响 了。情况就这样了，一天搏斗就是得出这个不算结论的结论。

Comments»

1. snailfly yin - December 26, 2006

lighttpd是web server,如果io吞吐量不足,无论怎么调整也没法超越IO这个瓶颈吧.如果在前端放置mod_mem_cache或用squid cache_dir null 做全内存cache不知道能不能解决?