Nginx+FastCGI运行Bugzilla的优化

我用Nginx+FastCGI的方式来运行我们的Bugzilla系统,但几天前的某一天发生过部分人访问出现nginx 503的情况,我看了下server端的error log,发现是Nginx连接FastCGI超时。简单说下我分析和解决问题的思路,和对Bugzilla性能优化的一点认识。

首先发现访问Bugzilla非常慢,等待十多秒钟后得到503错误;重启nginx就会基本解决,但过了一阵子有会出现这样的问题。显然,这段时间公司内使用Bugzilla的频率越来越高了(窃喜),但Bugzilla真的性能不是很好呀,访问量大了就有点撑不住了。

我看了下我的fastcgi_wrapper程序,其实就是网上比较标准的版本,没有什么明显漏洞。当看到“$socket = FCGI::OpenSocket( “127.0.0.1:8999”, 10 ); #use IP sockets”时,我想了下,会不会是TCP socket性能不高(我以前也在其他看到过类似的优化建议)。我就尝试用unix domain socket来代替TCP socket,如:$socket = FCGI::OpenSocket( “/var/run/bugzilla.perl.sock”, 10 ); #use unix domain socket. 用unix socket后,感觉性能没有明显提升,因为我当前的主要瓶颈不在这里;当然,在其他一些情况下,一般来说unix domain socket的性能还是会比TCP socket高不少的。

用了fastcgi的socket用了unix socket之后,过了几个小时,再次出现类似情况,我认为就肯定是其他问题导致的了。我看到OpenSocket函数的第二个参数是10,我就找文档看了下,原来它的意思是,当请求pending达到10个后就直接不响应了,而Bugzilla本来性能就不高,访问量较大时就会有较多的pending等待处理的请求,自然就会有人遇到直接503错误。我权衡了一下,就算让用户相应时间达到10s,也还是要正常处理请求的,这样还算基本能接受;而常碰到503就不能接受的,特别是我辛辛苦苦写了一个bug,结果submit时503了。所以我的方案是,就把10个pending的设置为100,之后就基本没有出现Bugzilla 503的用户反馈了。

另外,当改为unix socket domain时,在Nginx配置文件中,也要简单改下,如:fastcgi_pass unix:/var/run/bugzilla.perl.sock 。

如果要接着往后做性能优化,也可以将socket文件放到tmpfs这样内存文件系统中,其效率比放在磁盘上还会高一些;要是nginx+fastcgi未来确实不能满足需求,我觉得可以尝试一下用回Apache+mod_perl的部署架构,这是我多年前用的(不过Bugzilla服务的用户规模小,没有怎么特地去测试性能),据资料显示mod_perl的效率会比较高的。

Bugzilla作为20年前开始的一个项目,其本身基于比较落后的CGI技术,性能不是很好;当然,它也在不断进度,比如5.0版本就准备推出一些基于memcached的缓存机制,我们期待吧。

参考资料:
perl+fastcgi+nginx配置:http://www.ttlsa.com/nginx/perl-fastcgi-nginx/
bugzilla and performance 2014: https://globau.wordpress.com/2014/07/04/bugzilla-and-performance-2014/
apache mod_perl: http://perl.apache.org/
nginx_http_perl_module: http://nginx.org/en/docs/http/ngx_http_perl_module.html
nginx perl module配置: http://www.php-oa.com/2010/09/25/perl-perl-nginx.html

master

Stay hungry, stay foolish.

发表评论

电子邮件地址不会被公开。 必填项已用*标注