webman的processer分配邏輯是什么？
問(wèn)題描述
前端瀏覽器通常會(huì)同時(shí)給后端發(fā)送多個(gè)請(qǐng)求。在服務(wù)器空閑的時(shí)候，理論上應(yīng)該并發(fā)處理啊。為什么會(huì)出現(xiàn)排隊(duì)處理的情況。
測(cè)試案例：
用sleep 模擬延遲，在服務(wù)器空閑的時(shí)候，同一個(gè)方法三次請(qǐng)求會(huì)排隊(duì)執(zhí)行，并不會(huì)自動(dòng)使用空閑的 processer 。
同時(shí)調(diào)用不同的測(cè)試方法，也會(huì)出現(xiàn)排隊(duì)的情況，最多出現(xiàn)在兩個(gè) connections 中，還是會(huì)出現(xiàn)排隊(duì)。
每次請(qǐng)求應(yīng)該都是獨(dú)立的，不知道這個(gè) connection 是什么依據(jù)建立的。有沒(méi)有什么優(yōu)化方式？
4個(gè)回答
打賞
瀏覽器一般會(huì)復(fù)用連接，這個(gè)和瀏覽器復(fù)用連接機(jī)制有關(guān)，不是webman控制的。
我這里測(cè)試沒(méi)出現(xiàn)你說(shuō)的情況。
如果你預(yù)期自己的服務(wù)有慢請(qǐng)求，擔(dān)心慢請(qǐng)求會(huì)影響其它請(qǐng)求，可以在nginx代理那里關(guān)閉長(zhǎng)連接(刪除keepalive xxx配置)，
這樣每次請(qǐng)求nginx都會(huì)重新建立連接發(fā)給空閑的webman進(jìn)程。
換用 ab 測(cè)試工具，排除瀏覽器問(wèn)題，也不存在nginx代理。 10次請(qǐng)求，分散在5個(gè)processer 中，明顯有排隊(duì)
-
-
-
henian 2024-12-30
不開(kāi)啟reuseport 的情況， 這個(gè)分配感覺(jué)有點(diǎn)隨機(jī)性，不加延遲，測(cè)試10000次請(qǐng)求，并發(fā)100，倒是每個(gè)processer里面都有，但是分配也很不平均。 其中3-4個(gè)processer 占據(jù)了80%以上的請(qǐng)求。
-
-
henian 2024-12-30
好的，謝謝大佬。 我晚點(diǎn)找個(gè)linux環(huán)境測(cè)試下。 正常來(lái)說(shuō)，linux服務(wù)器推薦開(kāi)啟 reuseport 嗎？ 默認(rèn)怎么是 false ?
另外：我用ab測(cè)試(MacOs) 遇到幾個(gè)問(wèn)題，
一個(gè)是并發(fā)稍大就出現(xiàn) apr_socket_recv: Connection reset by peer (54)
一個(gè)是總請(qǐng)求數(shù)一多就會(huì)出現(xiàn)，apr_socket_recv: Operation timed out (60)
這個(gè)是哪里的限制？ 有什么可調(diào)參數(shù)嗎？ 還是硬件限制？ -
walkor 2024-12-30
如果有慢業(yè)務(wù)并且有nginx代理推薦nginx不開(kāi)keepalive，webman不開(kāi)reuseport。
如果有慢業(yè)務(wù)并且沒(méi)有nginx代理就推薦webman開(kāi)下reuseport。
沒(méi)有慢業(yè)務(wù)開(kāi)不開(kāi)reuseport差別不大。
mac os壓測(cè)本身有一些限制，具體我沒(méi)研究。
這個(gè)是在 Linux 環(huán)境下的測(cè)試，測(cè)試方法中延遲5秒
100個(gè)請(qǐng)求分散在16個(gè)不同processer中，理論上 最快也要 100 / 16 * 5 = 31 就算16個(gè)processer完全均分再排隊(duì)，最快也要30多秒。 為什么在分配不均勻的情況下，有的processer處理了15個(gè)請(qǐng)求，但是總得請(qǐng)求時(shí)間只有15秒。
看文檔描述，processer是單線執(zhí)行的，理論上要排隊(duì)啊。 越來(lái)越迷惑了。
-
walkor 2024-12-30
status 命令會(huì)打斷sleep(), 然sleep() 立刻返回，如果你一直執(zhí)行status或者執(zhí)行了status -d，時(shí)間會(huì)變少
-
henian 2024-12-30
果然，關(guān)閉status命令后，結(jié)果跟理論一致
不開(kāi) reusePort，分配不太平均，總體請(qǐng)求時(shí)間跟處理最多的請(qǐng)求*5 是一致的。
開(kāi)啟 reusePort 分配會(huì)平均一些，但是總請(qǐng)求時(shí)間反倒要長(zhǎng)了一些。 reusePort開(kāi)啟后會(huì)影響性能嗎？另外status命令，會(huì)中斷哪些類(lèi)型操作？ 不會(huì)只有sleep吧。 status會(huì)影響服務(wù)器的邏輯執(zhí)行，那這樣的話，在生產(chǎn)服務(wù)器上，不能開(kāi)著 status -d 觀察服務(wù)器情況？
-
walkor 2024-12-30
reusePort 對(duì)性能影響不好評(píng)估，reusePort是操作系統(tǒng)自動(dòng)分配連接給進(jìn)程，不考慮進(jìn)程繁忙程度。
不開(kāi) reusePort 是的時(shí)候是空閑進(jìn)程主動(dòng)認(rèn)領(lǐng)連接。
所以關(guān)于以上的各種情況可以自己腦補(bǔ)。status 目前看只對(duì)sleep有影響，文檔中也有說(shuō)明禁止使用sleep
