| 毫无疑问Apache是一个优秀的web server，但它也不万能的，在一些特定的环境下，也有Apache力不从心的时候。手上一台server由于瞬间高密度的访问非常多，因此Apache 1.3.x应付起来有点吃力，表现为响应速度慢，而且非常耗资源，Swap经常都是占满的。有一两次还导致机器负载过高（高达30-40，有个别时刻居然达到150之巨），感觉要死机的样子。
为此，必须寻求一个解决之道。分析之下，这台server目前的情况主要是由于运行了大量的fastcgi应用，而且这些应用的并发非常密集，平时白天就有200-300个连接，厉害的时候有近1000个在用进程。apache的运行情况top如下：
25806 nobody 15 0 7224 5888 1652 S 0.0 0.5 0:10 1 httpd28152 nobody 15 0 6576 5856 1680 S 0.0 0.5 0:01 1 httpd28686 nobody 15 0 7224 5808 1652 S 0.0 0.5 0:01 1 httpd
可见每个process的Share 内存就有1.6MB之多，如果是1000个进程就是1.6G了。加上其他开销，实际需要2G的存储空间，机器的内存是1G，交换区是1G，那实际上Swap将全部耗尽。
如何降低这些开销呢？fastcgi应用程序已经较好的优化了，耗费的资源很少，而且只有少于10个进程在运行，因此问题不在fastcgi。问题在Apache的并发响应能力，以及资源占用上。
使用lighttpd可以较好的解决这个问题，lighttpd基于单进程多路复用技术，因此消耗的资源非常少。而且支持fastcgi，但由于对php的支持仅限于fastcgi，与机器现有的一些网站并不能很好的兼容，因此考虑前端(80端口)用Apache，后端(2088)用lighttpd，通过rewrite技术，将fastcgi请求转交(Redirect)给后端的lighttpd处理。
这样原理上就能使apache的进程大幅度减少，并只是负责请求的转发而已，可以充分的利用原来的进程资源。而lighttpd消耗的cpu/memory资源也较低，因此完成同样的任务，Apache+lighttpd的方案就比原来的纯Apache要好得多。
实际运行证明，效率要好得多，响应速度提高了一个数量级以上。客户反映良好。
Apache rewrite + lighttpd 实现方法
原来负载较高的网站主机名highload.xxx.com ，运行的fastcgi prefix是/fcgi-bin。因此需要对这个虚拟主机进行Rewrite配置。
第一步，编译apache，激活mod_rewrite：./configure \
--with-layout=Apache --prefix=/usr/local/httpd \
--enable-shared=max --enable-module=rewrite \
--enable-shared=rewrite
安装并加载好之后，配置highload.xxx.com的虚拟主机，在VirtualHost里增加：RewriteEngine on
RewriteRule ^\/fcgi-bin\/(.+) http://highload.xxx.com:2088/$1
第二步，编译lighttpd，配置fastcgi并使lighttpd监听于2088端口：./configure --prefix=/usr/local/lighttpd
配置：server.modules = (
"mod_access",
"mod_fastcgi",
"mod_accesslog" )
server.document-root = "/var/www/vhost/highload/fcgi-bin/"
server.errorlog = "/var/log/lighttpd/lighttpd.error.log"
server.indexfiles = ( "index.php", "index.html",
"index.htm", "default.htm" )
mimetype.assign = (
".pdf" => "application/pdf",
".sig" => "application/pgp-signature",
".spl" => "application/futuresplash",
".class" => "application/octet-stream",
".ps" => "application/postscript",
".torrent" => "application/x-bittorrent",
".dvi" => "application/x-dvi",
".gz" => "application/x-gzip",
".pac" => "application/x-ns-proxy-autoconfig",
".swf" => "application/x-shockwave-flash",
".tar.gz" => "application/x-tgz",
".tgz" => "application/x-tgz",
".tar" => "application/x-tar",
".zip" => "application/zip",
".mp3" => "audio/mpeg",
".m3u" => "audio/x-mpegurl",
".wma" => "audio/x-ms-wma",
".wax" => "audio/x-ms-wax",
".ogg" => "audio/x-wav",
".wav" => "audio/x-wav",
".gif" => "image/gif",
".jpg" => "image/jpeg",
".jpeg" => "image/jpeg",
".png" => "image/png",
".xbm" => "image/x-xbitmap",
".xpm" => "image/x-xpixmap",
".xwd" => "image/x-xwindowdump",
".css" => "text/css",
".html" => "text/html",
".htm" => "text/html",
".js" => "text/javascript",
".asc" => "text/plain",
".c" => "text/plain",
".conf" => "text/plain",
".text" => "text/plain",
".txt" => "text/plain",
".dtd" => "text/xml",
".xml" => "text/xml",
".mpeg" => "video/mpeg",
".mpg" => "video/mpeg",
".mov" => "video/quicktime",
".qt" => "video/quicktime",
".avi" => "video/x-msvideo",
".asf" => "video/x-ms-asf",
".asx" => "video/x-ms-asf",
".wmv" => "video/x-ms-wmv",
".bz2" => "application/x-bzip",
".tbz" => "application/x-bzip-compressed-tar",
".tar.bz2" => "application/x-bzip-compressed-tar"
)
url.access-deny = ( "~", ".inc" )
server.port = 2080
fastcgi.server = ( "prog1" =>
("prog1" =>("socket" => "/tmp/prog1.socket")),
"prog2" =>
("prog2" =>("socket" => "/tmp/prog2.socket"))
)
这样lighttpd将监听于2088端口，访问http://highload.xxx.com:2088/prog1或prog2就可以执行fastcgi应用了。
注意，由于prog1/prog2等程序是非PHP 的fastcgi程序，由perl/c写成，因此必须用lighttpd的spawn-fcgi程序实现将这些fcgi应用运行，才能启动lighttpd，否则lighttpd会出错。进入/usr/local/lighttpd/bin，执行：
./spawn-fcgi -s /tmp/prog1.socket -f /var/www/vhost/highload/prog1
./spawn-fcgi -s /tmp/prog2.socket -f /var/www/vhost/highload/prog2
执行成功的话，将显示：spawn-fcgi.c.160: child spawned successfully: PID: 602
重新启动apache，这样凡是访问http://highload.xxx.com/fcgi-bin/prog1或prog2，将自动定向到http://highload.xxx.com:2080/prog*。
经过这样改进后，平均的Apache进程数从650-700降低到250，其余的400-500个并发就由lighttpd来处理。整机的负载也降低了很多。主要是内存使用大幅度降低了。只有原来的40%用量，swap余量非常足够:-)
而且最重要的是，响应速度快了很多。以下是并发请求的监视图：500)this.width=500'>
注意：图上显示的是按每秒的并发请求次数，而不是并发连接数，并发连接数大概是这个数的10倍，也即如果有25请求/秒，那么实际在一段时间内的持续并发连接数就有250-300个。 |
