« lighttpd,thttpd,shttpd - 轻量级webserver介绍 | Main | perl 性能优化 »
May 24, 2005
Apache rewrite技术实现Apache到lighttpd迁移
毫无疑问Apache是一个优秀的web server,但它也不万能的,在一些特定的环境下,也有Apache力不从心的时候。手上一台server由于瞬间高密度的访问非常多,因此Apache 1.3.x应付起来有点吃力,表现为响应速度慢,而且非常耗资源,Swap经常都是占满的。有一两次还导致机器负载过高(高达30-40,有个别时刻居然达到150之巨),感觉要死机的样子。
为此,必须寻求一个解决之道。分析之下,这台server目前的情况主要是由于运行了大量的fastcgi应用,而且这些应用的并发非常密集,平时白天就有200-300个连接,厉害的时候有近1000个在用进程。apache的运行情况top如下:
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\/(.+) 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余量非常足够:-)
而且最重要的是,响应速度快了很多。以下是并发请求的监视图:

注意:图上显示的是按每秒的并发请求次数,而不是并发连接数,并发连接数大概是这个数的10倍,也即如果有25请求/秒,那么实际在一段时间内的持续并发连接数就有250-300个。
Posted by hzqbbc at May 24, 2005 10:18 AM
Comments
不错,好文章!
关键在于要明白服务器的主要负载在什么地方。采用取长补短的方法来实现自己的应用,可以很好的挖掘服务器的潜力。
lighttpd的官方网站:http://www.lighttpd.net
没有用过这个web server,不知道它的性能到底如何,还望hzqbbc兄有后续的报导。关注中......
Posted by: huzi at May 26, 2005 03:24 PM
不错!很好做法!
好文章!!
Posted by: kylin at August 3, 2005 02:31 PM
不错!很妙的做法!
好文章!!
Posted by: kylin at August 3, 2005 02:33 PM
你好,最近需要使用php/fastcgi,所以在freebsd下安装了apahce2+mod_fastcgi+php4-cgi,具体安装我就不描述了,然后:
mkdir -p /usr/local/www/fcgi-bin
ln -s /usr/local/bin/php /usr/local/www/fcgi-bin/php
chown -R www:www /usr/local/www/fcgi-bin
mkdir -p /tmp/fcgi_ipc
chown -R www:www /tmp/fcgi_ipc
修改httpd.conf文件:
LoadModule actions_module libexec/apache2/mod_actions.so
LoadModule fastcgi_module libexec/apache2/mod_fastcgi.so
FastCgiIpcDir "/tmp/fcgi_ipc/"
FastCgiServer /usr/local/www/fcgi-bin/php -processes 10
ScriptAlias /fcgi-bin/ "/usr/local/www/fcgi-bin/"
AddHandler php-fastcgi .php
SetHandler fastcgi-script
Action php-fastcgi /fcgi-bin/php
AddType application/x-httpd-php .php
我的DocumentRoot "/export/test",我在其下建立了一个index.php文件,里面是phpinfo(),然后运行apache服务器,一切正常,但是从浏览器中查看这个index.php文件的时候,却出现了大篇幅的乱码。在error_log中也没有任何错误纪录。我将index.php中修改成 echo "aaaa";,然后查看这个index.php文件,依然是乱码,更奇怪的是,处理的依然是phpinfo()的内容。
请问这是什么原因?请hzqbbc帮忙解决。谢谢了。
Posted by: 匿名 at November 3, 2005 10:53 PM
楼上匿名的朋友,你说的这个问题我也没遇到过,而且我还没使用过php+fastcgi,至于您说web访问index.php是乱码,该不会是apache2中的AddDefaultCharset UTF-8作怪吧?
如果不是这个问题,会不会是php的fastcgi模式有问题?您打开了php支持fastcgi的选项否?
Posted by: hzqbbc at November 11, 2005 08:24 AM
谢谢你。问题已经解决了。
问题在这里,ln -s /usr/local/bin/php /usr/local/www/fcgi-bin/php,写了一个脚本代替这个php程序后问题解决。
http://new.pdx.cn/blog/diary,446543.html
Posted by: hlddn at November 18, 2005 01:28 PM
我想把静态的 /images/ 指到 lighttpd 如 http://image.xxx.com:8080/images 这个rewrite规则怎么写呀 :)
Posted by: danny at November 4, 2006 05:42 PM
直接用lighttpd绑80(抛弃apache)效果会不会更好?
不过lighttpd现在还没有mod_resin。。。。只好再架个apache了,呵呵
Posted by: bianbian at December 19, 2006 07:06 AM