onmessage是一条消息一条消息处理的?哪怕第一条消息涉及到网络操作,也要等第一条消息执行完毕,第二条消息才会执行? 输出
连着发送
是
。。难怪,驱动改成swoole有这个问题吗?
不清楚,没用过swoole
GetewayWorker本身就支持分布式部署,你有十万同时在线才需要考虑性能问题。 最先扛不住的反而是带宽。
为什么改成swoole扩展还是同步阻塞的处理请求了?
GetewayWorker 不支持协程,不要折腾了。 另外协程会有全局变量污染问题,不是引入协程就能用了,要了解协程负面影响才行。
为啥了?因为我们业务需要调用第三方接口,虽然其他业务处理很快,但是如果一次100个用户进来,都要调用第三方接口,那不全部挂了
那webman支持?
第三方接口用 workerman/http-client
就算用这个异步的,这个进程是不是要等这个第三方接口响应了,走完所有业务代码,才能处理下一个请求
gatewayWorker里用了$_SESSION全局变量,协程会导致$_SESSION错乱。 webman本身支持swoole协程,但是composer的其它组件不支持协程,例如tp-rom laravel-orm
swoole不是支持一键协程码?另外,好像同一个连接的不同消息都是在一个bussiness进程处理的?我们现在有个项目打算不用http,用ws协议,用户进入后,可能会发送20多条 消息,这样岂不是完成整个首页加载,时间是20多条消息的耗时总和?
swoole的一键协程需要你使用swoole的那一整套东西
哦,好吧
是
。。难怪,驱动改成swoole有这个问题吗?
不清楚,没用过swoole
GetewayWorker本身就支持分布式部署,你有十万同时在线才需要考虑性能问题。
最先扛不住的反而是带宽。
为什么改成swoole扩展还是同步阻塞的处理请求了?
GetewayWorker 不支持协程,不要折腾了。
另外协程会有全局变量污染问题,不是引入协程就能用了,要了解协程负面影响才行。
为啥了?因为我们业务需要调用第三方接口,虽然其他业务处理很快,但是如果一次100个用户进来,都要调用第三方接口,那不全部挂了
那webman支持?
第三方接口用 workerman/http-client
就算用这个异步的,这个进程是不是要等这个第三方接口响应了,走完所有业务代码,才能处理下一个请求
gatewayWorker里用了$_SESSION全局变量,协程会导致$_SESSION错乱。
webman本身支持swoole协程,但是composer的其它组件不支持协程,例如tp-rom laravel-orm
swoole不是支持一键协程码?另外,好像同一个连接的不同消息都是在一个bussiness进程处理的?我们现在有个项目打算不用http,用ws协议,用户进入后,可能会发送20多条 消息,这样岂不是完成整个首页加载,时间是20多条消息的耗时总和?
swoole的一键协程需要你使用swoole的那一整套东西
哦,好吧