我用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的缓存机制，我们期待吧。