一定压力下，会有client的报错

[wangbon]

在comet节点单独使用4u8g ,2台client使用4u8G的低速服务器，./client 1 12500 XXXXX 然后push节点./push_room 1 40 XXXX ，在client节点就有如下报错，这个是啥原因（我看所有服务器的cpu和内存使用率都不到一半），是需要做什么调优还是有什么限制？还希望大神解答 谢谢 E0219 20:32:55.316955 3916 main.go:167] key:8296 tcpReadProto() error(read tcp 192.168.0.159:49366->192.168.0.67:3101: i/o timeout)

[tonybase]

这个因素很多，比较虚拟机的网络会比较差一些，还有看下流量，是否公网环境。长连接在物理机环境会比较稳定，建议在内网中进行压测。

[wangbon]

华为云内网测试的，这个确实比较复杂，我就是下来问问思路或者有啥注意点的， 谢谢啦 我再排查排查

[wangbon]

换了性能更好的client测试就没有问题，怀疑是因为client里有大量的log写，导致的问题！（频繁写导致长连接得不到调度？然后超时么。。。我瞎猜的，说错了还请见谅） 在测试的一个小时内，部署了discovery,redis，job,logic，kafka的虚拟机，内存使用率会持续增长，到一定阶段之后不再增长，是kafka的原因吗，推测：kafka对消息缓存一定量到内存里，然后达到max之后，只做消息的以新换旧，但是内存不再增长了？我没有修改过代码，也没有增加认证之类的。谢谢

[tonybase]

可以提mr看看client不的，内存可以看看具体是哪个进程使用

[wangbon]

可以提mr看看client不的，内存可以看看具体是哪个进程使用

client就是源代码里写的/benchmarks/client目录下的源码。但是有很多log 记录auth ok之类的，之前的client机器处理能力差（后来我就把client的log就都注释了），与comet建立了50000长连接，并且每秒40的推送（push也是相应源代码里直接拿来用的）。至于mr 是不是就是我在Pull request里写代码提交给您？（目前还没那个能力哈）！另再问一个问题，在很多长连接并且有房间内广播的压力，comet很容易就kill了（就Comet节点是单机部署的），应该是没内存了，具体是什么原因造成的？（我的client都能及时处理comet消息 不会造成消息堆积于长连接断开）。 谢谢作者咯！ 谢谢耐心~

[tonybase]

那应该是内存不足OOM了

[wangbon]

那应该是内存不足OOM了

对的，这个我了解哈，我的疑问是什么操作造成的，就是代码逻辑部分的部分，我还看不懂这个源码，有点伸手党咯，抱歉! 谢谢啦