onmessage是一條消息一條消息處理的?哪怕第一條消息涉及到網(wǎng)絡(luò)操作,也要等第一條消息執(zhí)行完畢,第二條消息才會(huì)執(zhí)行?
輸出
連著發(fā)送
GetewayWorker本身就支持分布式部署,你有十萬(wàn)同時(shí)在線(xiàn)才需要考慮性能問(wèn)題。
最先扛不住的反而是帶寬。
GetewayWorker 不支持協(xié)程,不要折騰了。
另外協(xié)程會(huì)有全局變量污染問(wèn)題,不是引入?yún)f(xié)程就能用了,要了解協(xié)程負(fù)面影響才行。
為啥了?因?yàn)槲覀儤I(yè)務(wù)需要調(diào)用第三方接口,雖然其他業(yè)務(wù)處理很快,但是如果一次100個(gè)用戶(hù)進(jìn)來(lái),都要調(diào)用第三方接口,那不全部掛了
就算用這個(gè)異步的,這個(gè)進(jìn)程是不是要等這個(gè)第三方接口響應(yīng)了,走完所有業(yè)務(wù)代碼,才能處理下一個(gè)請(qǐng)求
gatewayWorker里用了$_SESSION全局變量,協(xié)程會(huì)導(dǎo)致$_SESSION錯(cuò)亂。
webman本身支持swoole協(xié)程,但是composer的其它組件不支持協(xié)程,例如tp-rom laravel-orm
swoole不是支持一鍵協(xié)程碼?另外,好像同一個(gè)連接的不同消息都是在一個(gè)bussiness進(jìn)程處理的?我們現(xiàn)在有個(gè)項(xiàng)目打算不用http,用ws協(xié)議,用戶(hù)進(jìn)入后,可能會(huì)發(fā)送20多條 消息,這樣豈不是完成整個(gè)首頁(yè)加載,時(shí)間是20多條消息的耗時(shí)總和?