webman+gatewaywork ，php 8.3,安裝了events擴展，處理請求是同步的嗎

pengzhen 2024-10-24

onmessage是一條消息一條消息處理的？哪怕第一條消息涉及到網(wǎng)絡(luò)操作，也要等第一條消息執(zhí)行完畢，第二條消息才會執(zhí)行？

輸出

連著發(fā)送

 663  4 1

nitron 2024-10-24

是

efnic 2024-10-24

GetewayWorker本身就支持分布式部署，你有十萬同時在線才需要考慮性能問題。
最先扛不住的反而是帶寬。

pengzhen 2024-10-25

為什么改成swoole擴展還是同步阻塞的處理請求了？

walkor 2024-10-25

打賞

GetewayWorker 不支持協(xié)程，不要折騰了。
另外協(xié)程會有全局變量污染問題，不是引入?yún)f(xié)程就能用了，要了解協(xié)程負面影響才行。

pengzhen 2024-10-25

為啥了？因為我們業(yè)務(wù)需要調(diào)用第三方接口，雖然其他業(yè)務(wù)處理很快，但是如果一次100個用戶進來，都要調(diào)用第三方接口，那不全部掛了
pengzhen 2024-10-25

那webman支持？
walkor 2024-10-25

第三方接口用 workerman/http-client
pengzhen 2024-10-25

就算用這個異步的，這個進程是不是要等這個第三方接口響應(yīng)了，走完所有業(yè)務(wù)代碼，才能處理下一個請求
walkor 2024-10-25

gatewayWorker里用了$_SESSION全局變量，協(xié)程會導(dǎo)致$_SESSION錯亂。
webman本身支持swoole協(xié)程，但是composer的其它組件不支持協(xié)程，例如tp-rom laravel-orm
pengzhen 2024-10-25

swoole不是支持一鍵協(xié)程碼？另外，好像同一個連接的不同消息都是在一個bussiness進程處理的？我們現(xiàn)在有個項目打算不用http，用ws協(xié)議，用戶進入后，可能會發(fā)送20多條消息，這樣豈不是完成整個首頁加載，時間是20多條消息的耗時總和？
nitron 2024-10-25

swoole的一鍵協(xié)程需要你使用swoole的那一整套東西
pengzhen 2024-10-25

哦，好吧