标题:
最近模拟测试发现,当用1000个机器人进去同一个场景(同一个进程),以每100ms发送一条请求给到服务器,再做AOI广播给附近机器人。 会出现服务缓存的数据包过多, 甚至出现 把robot进程关闭后, 过一个小时服务器仍然还在处理发送过来的消息。 同时其他的请求也出现过度的延迟。由于缓存包数量过大, 内存也会暴涨。 像这种情况除了优化单进程人数和消息量外,有没有更好的处理方案,比如开始丢弃处理不过来的包,让玩家掉线, 让服务器快速释放掉压力, 不至于一直高负荷运行,导致玩家各种卡顿。
1000个人,100ms发一条,那就是一秒10条,每条要广播给1000人,那么一秒要发1000 * 1000 * 10=1000W条,你说哪个进程一秒能发这么多
egametang AOI广播有范围,范围覆盖大概是20人左右。1s大概20w条
20W条也很多了,单进程能力一秒5w左右
egametang 5w的瓶颈是CPU的能力限制吗?而且ET7增加了网络线程,不知道这方面是否有提升?我在用aws做压测,大约3w就会产生客户端连接超时断线的问题。
这测试有啥意义,测上限?
Long 是的, 测试下单进程能承载多少人数, 游戏消息量比较大。各方面测试下压力,测试出承载量。
写一个limt组件挂在session上,这个组件在session接受消息的地方判断,如果是你测试的高频协议,频率过高直接抛弃或者返回error回去。
同样这个组件也可以拦截任何你设置的高频协议,如登陆注册等
gxbgtt 这个可以解决恶意刷协议,或者一些可以控制频率的协议, 我这个游戏,通讯量确实比较大,频繁。 只能从承载上下手了。单进程控制合理的数量。 多拆开进程去分压了。
是可以写个组件,判断每秒收到的消息数量,超过一定数量就断开session,这个判断可以放到SessionStreamDispatcherServerOuter中去判断,不需要修改session的代码,要注意软路由会自动重连的情况,会导致一瞬间出现大量消息,不过一般也不会超过100个,基本上限制成100就行了
egametang 这样会不会存在误操作 某些业务某些玩家可能因为开启了脚本(假设游戏默认允许开脚本处理业务) 这时候玩家是不是会被误判而导致断线 实际线上对于这种收发量断线的处理是有很大的容忍度的
脚本也不能允许一秒超过100个消息,不然岂不是随便攻击你的服务器
aznable ET7回来20W包一秒,看github的readme,上面写了