进程阻塞的问题。客户端请求到返回花费超过30秒
问题描述
在线人数多的时候。客户端发送了一个请求。业务处理逻辑只花了0.1353秒。
但是客户端发送过来的时间到返回时间总得却花费了接近10万毫秒。客户端等待了1.7分钟才拿到了返回。
业务逻辑只有0.13秒。从进入 onMessage 到 send 时间是比较短。但是在客户端发送请求，到调入到onMessge里却等待了超过1分钟.
请问是什么原因导致的？是我用法不对还是什么原因？
注：http短连接。
部分日志
string(113) "onLogin 耗时==0.041 2=0.01 3=0.082 fun0=\gamelogic\processPlayerNet func1=onLogin loginname=xiaobao006"
请求到返回所花费时间 holy shit: 99897ms
121.35.96.220 - 2020-02-07 00:03:56 - POST - /game - HTTP/1.1 - NULL - 200 - 0.1353s
2007 1 0
1个回答
相似问题
年代过于久远，无法发表回答
感觉有以下可能性。
可能性一：业务逻辑处理虽然只有0.13秒，但是请求量比较大，请求大量挤压，导致进入onMessage延迟。
拿单个进程来说，业务逻辑处理耗时0.13秒，如果瞬间有1000个请求压到这个进程来，就会有个别请求等待
0.13*1000=130秒才进入到onMessage，这样就会出现这种现象了。可能性二：还有就是看下是不是没装event扩展，手册说并发连接数超过1000需要装event扩展，否则会有请求延迟。
还有就是看下是不是个别接口的问题，还是每个接口都有类似问题。如果只有个别接口有这种现象可以考虑接口写的有bug，比如接口里某个if else分支根本没有调用send给客户端发送数据，导致客户端傻等。
我目前测试是开了单进程，模拟1000用户在线。发送请求频率 0.5-1秒1次。
另外，我这边 装了event
不是说单经常可以支持上万并发吗？为啥这千人在线，并发就几百就不行了呢
你可以这么理解，框架可以支持单进程上万并发，但是业务代码不一定支持上万并发。并不是框架能支持上万并发，业务代码怎么写也都能支持上万并发，如果是这样的话，也就没有架构师的职业了你说是吧。如果你的业务处理速度赶不上请求速度，瓶颈在业务了。如果业务无法优化得更快，需要开多进程甚至多服务器来解决了。