所以按照以往的经验, 卡牌类型的游戏1.0~2.0qps, 那么这个ARPG游戏服务器可能就0.5~1.0qps的样子.
采集数据
最开始处理的MongoDB的读写数据采样....按照我们的估算, load一个玩家需要10个DB操作, 一个玩家在线大概只需要0.5~1.0个DB操作. 但是我们用机器人去跑, 发现处理MongoDB读写的队列经常因为过大, 进而系统OOM....MongoDB IO的处理
最开始用机器人做压力测试, DB队列总是会OOM. 经过采样和分析, 发现:
1、绝大部分操作都是道具上的
道具占最多这个是能想到的....但是单独写一个写DB的Benchmark程序去直连MongoDB就是好的.
虽然减少了很多不必要的DB操作, 系统略微可以使用, 但是单独这个优化是没有解决DB操作变长这个问题....这个系列文章里面大篇幅都围绕着内存分配, 整个过程下来, 对算法的优化几乎没有, 服务器内甚至连AOI都没有做, 就是去场景内定时遍历维护视野列表(可以理解为N^2时间复杂度, N上限是40~50).