How to optimize Nginx + FastCGI to run Bugzilla

I used Nginx + FastCGI to run our Bugzilla system, but some people visited nginx 503 a few days ago. I checked the error log on the server, it is found that Nginx connection FastCGI times out. Let me briefly describe my ideas on analyzing and solving problems, and my understanding of Bugzilla performance optimization.

First, it was found that the access to Bugzilla was very slow. Wait for more than 10 seconds and get the 503 error. Restart nginx will basically solve the problem, but this problem will occur after a while. Obviously, the frequency of using Bugzilla in the company is getting higher and higher during this time (stealing), but the performance of Bugzilla is really not very good, and the traffic volume is too large to support it.

I read my fastcgi_wrapper program, which is a standard version on the Internet and has no obvious vulnerabilities. When I saw "$ socket = FCGI: OpenSocket (" 127.0.0.1: 8999 & Prime;, 10); # use IP sockets ", I thought about it, will it be that the performance of TCP socket is not high (I have seen similar optimization suggestions before ). I tried to use unix domain socket instead of TCP socket, for example: $ socket = FCGI: OpenSocket ("/var/run/bugzilla. perl. sock ", 10); # use unix domain socket. after using unix socket, I feel that the performance is not significantly improved, because my current major bottleneck is not here; of course, in other cases, generally, the performance of unix domain socket is much higher than that of TCP socket.

After using fastcgi socket with unix socket, after a few hours, a similar situation occurs again, and I think it must be caused by other problems. I can see that the second parameter of the OpenSocket function is 10. I went to the document and read it. It originally meant that when the number of pending requests reaches 10, the system did not respond directly, the performance of Bugzilla is not high. When the traffic volume is large, there will be a large number of pending requests waiting for processing. Naturally, someone will encounter a direct 503 error. I have made a trade-off. Even if the user's corresponding time reaches 10 s, the user still needs to process the request normally, which is basically acceptable, and 503 is unacceptable, in particular, I worked hard to write a bug, and the result was 503 at the time of submit. So my solution is to set 10 pending to 100, and then there will be basically no user feedback from Bugzilla 503.

In addition, when changing to a unix socket domain, you should also change it in the Nginx configuration file, for example, fastcgi_pass unix:/var/run/bugzilla. perl. sock.

If you want to optimize the performance later, you can also put the socket file in a memory file system like tmpfs, which is more efficient than on the disk; if nginx + fastcgi does not meet the requirements in the future, I think we can try to use the deployment architecture of Apache + mod_perl, which I used many years ago (however, the Bugzilla service has a small user base, not how to specifically test the performance), according to the data shows that the efficiency of mod_perl is relatively high.

As a project started 20 years ago, Bugzilla is based on a relatively backward CGI technology and has poor performance. Of course, it is constantly improving, for example, Version 5.0 is about to launch some memcached-based caching mechanisms. Let's look forward to it.