webman的processer分配逻辑是什么？
问题描述
前端浏览器通常会同时给后端发送多个请求。在服务器空闲的时候，理论上应该并发处理啊。为什么会出现排队处理的情况。
测试案例：
用sleep 模拟延迟，在服务器空闲的时候，同一个方法三次请求会排队执行，并不会自动使用空闲的 processer 。
同时调用不同的测试方法，也会出现排队的情况，最多出现在两个 connections 中，还是会出现排队。
每次请求应该都是独立的，不知道这个 connection 是什么依据建立的。有没有什么优化方式？
296 4 2
4个回答
相似问题
浏览器一般会复用连接，这个和浏览器复用连接机制有关，不是webman控制的。
我这里测试没出现你说的情况。
如果你预期自己的服务有慢请求，担心慢请求会影响其它请求，可以在nginx代理那里关闭长连接(删除keepalive xxx配置)，
这样每次请求nginx都会重新建立连接发给空闲的webman进程。
使用 ab 工具又测试了下，还是有这个问题。 详见下面独立评论，有截图
在Linux下测试了下， 见最新评论，不太清楚具体是什么原因，烦请大佬解释下。
换用 ab 测试工具，排除浏览器问题，也不存在nginx代理。 10次请求，分散在5个processer 中，明显有排队
如果你的业务不走nginx，想让连接平均分配到各个进程，开启reuseport就好了
开启之后，反倒更集中了啊， ab测试的10个请求，都在一个 processer 里面
不开启reuseport 的情况， 这个分配感觉有点随机性，不加延迟，测试10000次请求，并发100，倒是每个processer里面都有，但是分配也很不平均。 其中3-4个processer 占据了80%以上的请求。
你是Mac OS吧，PHP在Mac OS不支持 reuseport
好的，谢谢大佬。 我晚点找个linux环境测试下。 正常来说，linux服务器推荐开启 reuseport 吗？ 默认怎么是 false ?
另外：我用ab测试(MacOs) 遇到几个问题，
一个是并发稍大就出现 apr_socket_recv: Connection reset by peer (54)
一个是总请求数一多就会出现，apr_socket_recv: Operation timed out (60)
这个是哪里的限制？ 有什么可调参数吗？ 还是硬件限制？
如果有慢业务并且有nginx代理推荐nginx不开keepalive，webman不开reuseport。
如果有慢业务并且没有nginx代理就推荐webman开下reuseport。
没有慢业务开不开reuseport差别不大。
mac os压测本身有一些限制，具体我没研究。
这个是在 Linux 环境下的测试，测试方法中延迟5秒
100个请求分散在16个不同processer中，理论上 最快也要 100 / 16 * 5 = 31 就算16个processer完全均分再排队，最快也要30多秒。 为什么在分配不均匀的情况下，有的processer处理了15个请求，但是总得请求时间只有15秒。
看文档描述，processer是单线执行的，理论上要排队啊。 越来越迷惑了。
status 命令会打断sleep(), 然sleep() 立刻返回，如果你一直执行status或者执行了status -d，时间会变少
果然，关闭status命令后，结果跟理论一致
不开 reusePort，分配不太平均，总体请求时间跟处理最多的请求*5 是一致的。
开启 reusePort 分配会平均一些，但是总请求时间反倒要长了一些。 reusePort开启后会影响性能吗？
另外status命令，会中断哪些类型操作？ 不会只有sleep吧。 status会影响服务器的逻辑执行，那这样的话，在生产服务器上，不能开着 status -d 观察服务器情况？
reusePort 对性能影响不好评估，reusePort是操作系统自动分配连接给进程，不考虑进程繁忙程度。
不开 reusePort 是的时候是空闲进程主动认领连接。
所以关于以上的各种情况可以自己脑补。
status 目前看只对sleep有影响，文档中也有说明禁止使用sleep
总结：佬们的基本功真扎实👍。这些鄙人一点不懂（但丝毫不影响使用，哈哈.gif）。
排队