那么对于nginx，对于php-fpm，backlog应该设置多大，是越大越好吗？backlog怎么设置合适？这是上篇文章中遗留的几个问题
接着上篇文章Nginx高并发调优中常被忽略的参数中，最后部分，通过查看nginx源码发现nginx源码中定义backlog为511，其实在php-fpm配置文件中，同样默认backlog是511
包括redis，在默认配置文件中也有backlog配置，默认也是511
其实在redis注释中已经解释很清楚了，当你需要处理高并发得场景时，需要较大得backlog来处理堆积得请求，上篇文章对原理已经做了较全面的解释，网上也有很多大牛关于tcp全连接、半连接的文章讲解，今天主要想测试下，backlog在优化设置时，应该怎么设置
为了尽量排除带宽影响，我这里直接用两台内网的机子，一台作为客户端用ab去请求，另外一台作为服务端，服务端是一台centos7，没有优化过的系统
首先说一下ss的Recv-Q和Send-Q
在ss命令的结果中，如果该条记录为监听端口，则Recv-Q表示accept队列中元素的个数，Send-Q表示accept队列中队列的容量，所以从监听端口这行正好可以看到队列的情况
接着开始测试，第一步，先就默认backlog为128的情况下，用ab进行测试
直接开了两个窗口，用watch执行ss命令，0.1s刷新，在客户端用ab 200并发请求，开始瞬间php的Recv-Q就满了(因为我这里nginx连接php用的是socket的方式，所以监听的是socket，不是端口)，接着查看ab结果
69次失败请求
查看nginx错误日志，69条错误日志，都是sock文件资源不可用，如果是用端口的形式，应该是请求超时或连接被重置，这个具体根据php执行时间已经nginx配置超时时间决定
接着调大内核somaxconn，让somaxconn大于nginx和php的默认backlog，也就是511，这里设置为1024，在接着测试
查看php-cgi的Send-Q，注意这里nginx或者php-fpm都要restart才能生效
接着查看nginx的Send-Q
接着ab进行测试，同时实时查看Recv-Q情况，我先仍然用刚才的ab参数进行测试
截图有点慢了，打的时候Recv-Q已经到198了，接着快速下降，看下ab测试结果
已经没有失败请求了，接着调大ab参数，再进行同样的测试
手慢了，ab打的瞬间Recv-Q是512，队列打满了，接着查看结果，不出意外肯定会有失败请求
从目前测试的结果来看，最直观的就是，backlog增大，对于能处理的并发请求来说也在增大，所以backlog优化是必须的，接着继续增加backlog进行测试
还是用600并发
没有问题，都能够正常处理，继续增加并发到1025
查看结果
接着想看下backlog太大会不会有什么影响，进行如下配置
接着ab测试(测试服务器不一定能扛住，这里ab最大并发2w)
从结果来看，没有问题，backlog越大越好
但其实这里有个问题，就是我这里测试的只是单php脚本，并没有涉及到业务代码，也不查询数据库，所以php能够快速处理，服务器不会崩，那么为什么nginx、php-fpm、redis，都默认设置511，而不设置很大的值，其实在php历史上，backlog是修改过的(从其他文章看到的)，也是从511，修改到65535，提交者也是认为backlog数量越大越好，即便出现timeout也比syn队列满了后，内核忽略掉TCP SYN请求要好
但是在后面又将backlog改回511
其中理由是“backlog值为65535太大了。会导致前面的nginx（或者其他客户端）超时”，而且提交者举例计算了一下，假设FPM的QPS为5000，那么65535个请求全部处理完需要13s的样子。但前端的nginx（或其他客户端）已经等待超时，关闭了这个连接。当FPM处理完之后，再往这个SOCKET ID 写数据时，却发现连接已关闭，得到的是“error: Broken Pipe”，在nginx、redis、apache里，默认的backlog值都是511。故这里也建议改为511
所以我的建议是，用压测的方法，持续调整测试，取一个适合你业务的最大backlog值，一定要以业务代码进行测试，而不是单纯的调大backlog。
