nginx + php(fpm) 提高并发性调优实战

因为听说nginx的并发性能比apache好，突发奇想想要测试一下，装好了nginx和php-fpm,用ab进行测试。 结果发现请求静态文件的话，nginx的确比apache性能更好。可是如果是访问php文件，我发现并发500的情况下nginx完败给apache。 这肯定是我的测试方法有问题。

因为听说nginx的并发性能比apache好，突发奇想想要测试一下，装好了nginx和php-fpm,用ab进行测试。

结果发现请求静态文件的话，nginx的确比apache性能更好。可是如果是访问php文件，我发现并发500的情况下nginx完败给apache。

这肯定是我的测试方法有问题。

基于此，我觉得ab这个工具只能给出一个结果，却不知道服务器返回的内容是什么，所以我决定写一个PHP版本的benchmark工具。

而关于做压力测试，redis的作者就曾经写过一篇文章How fast is redis，用来对比redis和memcached的性能,里面说了很多压力测试需要注意的方面，比如说：

1.带宽（就算服务器的性能非常高了，你只有10kbits的带宽是测试不出它的性能瓶颈的）。

2.被测试机和测试机不该放在同一主机上。

3.被测试的软件的硬件环境会影响软件性能（比如说redis是单线程的，memcached是多线程的，在多核计算机上测试更利于memcached）。

4.N并行的并发性访问应该是N个客户端的轮询，而不要单个客户端的不断重复请求。

我的测试方法是用PHP同时发起请求，请求一个里面带有sleep(10000)的PHP页面，那样我就可以知道我的nginx到底可以同时处理多少个PHP连接了。

结果发现他只能同时处理几十个连接，我差点哭晕在厕所（查看连接数使用  ss |grep http |wc -l )；

所谓知己知彼，百战不殆。我们需要知道nginx和fastcgi的运行原理来解决这个问题，请看大神文章nginx工作原理与优化。

nginx处理PHP请求有三个步骤。

第一步：接受请求，发现是PHP请求，转向第二步。

第二步：通过socket的方式，连接PHP-FPM的fast-cgi,让PHP-FPM处理请求。

第三步：获得PHP-FPM处理结果，加上http报头，返回给客户端。

所以，我们要提高nginx的PHP并发性能，我们需要做这三步。

1.调大nginx的并发连接数（ 调nginx.conf  的worker_connections ）。

2.调大php-fpm的并发连接数（调php-fpm.conf  的pm.max_children等，具体看manual)。

3.增加系统的最大文件数量限制(ulimit -n 10000  该命令设置为10000)。

为什么我们需要第三步呢，因为NGINX处理PHP请求的第二步需要通过socket的方式和PHP-FPM通信，它能新建的最大socket数受到系统最大打开文件数的限制。

根据木桶效应，上面三步中的最小的那一步，就决定了nginx处理PHP请求的最小并发量。

反思：因为做实验的时候太过迷信ss命令，就一直用它和awk,grep组合来查看网络连接数，反而忽略了看nginx日志来解决问题（这也是认知失调的自我辩护的一种吧）。以后有问题还是要多看日志，共勉）。