毫无疑问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 httpd
28152 nobody 15 0 6576 5856 1680 S 0.0 0.5 0:01 1 httpd
28686 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\\/(.+) $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端口，访问
注意，由于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，这样凡是访问*。
经过这样改进后，平均的Apache进程数从650-700降低到250，其余的400-500个并发就由lighttpd来处理。整机的负载也降低了很多。主要是内存使用大幅度降低了。只有原来的40%用量，swap余量非常足够:-)
而且最重要的是，响应速度快了很多。以下是并发请求的监视图：
注意：图上显示的是按每秒的并发请求次数，而不是并发连接数，并发连接数大概是这个数的10倍，也即如果有25请求/秒，那么实际在一段时间内的持续并发连接数就有250-300个。
