BusinessWorker面对高并发出现busy

新人更新于2018-07-12

最近BusinessWorker 接收消息面对高并发请求(每秒起码几十条数据,每条数据50-100字节)就会出现busy,没有操作数据库之类的只是做转发处理,从出现的情况来看和连接数也多少也没有直接关系,查看日志后里面让我去看: See http://wiki.workerman.net/Error2 for detail 这个网页,看了后说是业务造成死循环导致的,但是从我代码来看并不会出现死循环,随后我在发送消息时我在业务处理前监测它,但是并没有第一时间收到数据,而我在业务处理完后也监测它,只要我接收消息就在业务处理中就不会产生延迟,说明是在发送信息中就阻塞的,说得有点长和啰嗦,没明白的我可以再解释

 5002  1 0

1个回答

walkor 2018-07-12

打赏

可能是客户端发送的消息速度快于你业务处理的速度。
比如所有客户端加起来每秒向服务端发送100个消息，而服务端处理一个消息要20毫秒，那么服务端每秒只能处理50个消息(只有一个businessWorker进程情况下)，那么每秒就会有50个消息没处理积压在队列，随着时间推移队列里数据一直积压直到队列满，然后就报 sendbuffertoworker fail.may be the send buffer are overflow 错了。不要想着增加队列大小解决这个问题，只能稍稍缓解，无法根本解决。

如果businessWorker进程里的业务逻辑有死循环或者长时间阻塞，或者其它耗时的任务，也会大大降低businessWorker进程进程处理消息的速度，更容易造成sendbuffertoworker fail.may be the send buffer are overflow 错误。

你可以计算下服务端处理每个请求的时间，还有客户端发送的速率，看看是否能够及时的处理每个请求而不一直积压。

解决这个问题的关键就是处理请求的速度够快。

新人 2018-07-12

5行代码,用了4个workerman方法,joinGroup,getClientCountByGroup,bindUid,sendToGroup,
walkor 2018-07-12

这几个方法中getClientCountByGroup是比较耗时的，getClientCountByGroup和sendToGroup，比较耗系统资源。
新人 2018-07-12

@1:那么这个问题是不是就是个硬性问题了,只能减少发送数据才能解决,还有个问题,安装了event扩展后还用不用做什么操作,查看资料还要编写event的代码,这就很懵逼了
walkor 2018-07-12

嗯，服务器硬件+框架+业务代码结合在一起肯定有个极限，并非多大的请求量服务端都能承受。event扩展安装成功了就自动使用了，不用其它编码。