因为听说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日志来解决问题（这也是认知失调的自我辩护的一种吧）。以后有问题还是要多看日志，共勉）。
