Nginx + php (fpm) to improve concurrency tuning practices

I heard that nginx has better concurrent performance than apache, and I want to test it. I have installed nginx and php-fpm and tested it with AB. The results show that nginx has better performance than apache in requesting static files. However, if you access the PHP file, I find that nginx is defeated to apache when the concurrency is 500. This is definitely a problem with my testing method.

I heard that nginx has better concurrent performance than apache, and I want to test it. I have installed nginx and php-fpm and tested it with AB. The results show that nginx has better performance than apache in requesting static files. However, if you access the PHP file, I find that nginx is defeated to apache when the concurrency is 500. This is definitely a problem with my testing method.

I heard that nginx has better concurrent performance than apache, and I want to test it. I have installed nginx and php-fpm and tested it with AB.

The results show that nginx has better performance than apache in requesting static files. However, if you access the PHP file, I find that nginx is defeated to apache when the concurrency is 500.

This is definitely a problem with my testing method.

Based on this, I think the AB tool can only give one result, but I don't know what the server returns. So I decided to write a PHP benchmark tool.

For stress testing, the author of redis once wrote an article on How fast is redis to compare the performance of redis and memcached, which describes a lot of considerations for stress testing, for example:

1. bandwidth (even if the server performance is very high, you only have 10 kbits of bandwidth and cannot test its performance bottleneck ).

2. The tested and tested machines should not be placed on the same host.

3. The hardware environment of the tested software will affect the software performance (for example, redis is single-threaded, memcached is multi-threaded, and testing on multi-core computers is more conducive to memcached ).

4. N concurrent access should be round-robin by N clients instead of repeated requests from a single client.

My test method is to use PHP to initiate a request simultaneously and request a PHP page containing sleep (10000, then I can know how many PHP connections can be processed simultaneously by nginx.

It turns out that he can only process dozens of connections at the same time, and I almost cried out in the toilet (view the number of connections using ss | grep http | wc-l );

The so-called "Know Yourself" and "Know Yourself" cannot be defeated. We need to know the operating principles of nginx and fastcgi to solve this problem. Please refer to the nginx working principles and optimization article.

Nginx has three steps to process PHP requests.

Step 1: accept the request and find it is a PHP request.

Step 2: connect the fast-cgi of the PHP-FPM through the socket to let the PHP-FPM handle the request.

Step 3: Get the PHP-FPM processing result, add the http header, and return to the client.

Therefore, we need to perform these three steps to improve the PHP concurrency performance of nginx.

1. Increase the number of concurrent nginx connections (call nginx. conf worker_connections ).

2. Increase the number of concurrent connections of php-fpm (tune the pm. max_children of the php-fpm.conf, etc. For details, see manual ).

3. Increase the maximum number of files in the system (ulimit-n 10000 this command is set to 10000 ).

Why do we need the third step, because NGINX needs to communicate with the PHP-FPM through socket in the second step of processing PHP requests, the maximum number of sockets it can create is limited by the maximum number of files opened by the system.

According to the bucket effect, the smallest step in the preceding three steps determines the minimum concurrency for nginx to process PHP requests.

Reflection: Because the experiment was too superstitious about the ss Command, we always used it in combination with awk and grep to view the number of network connections, instead, the nginx log is ignored to solve the problem (this is also a self-defense of cognitive disorder ). If you have any questions in the future, please read the logs ).