前言
优化服务器之前, 需要先对问题的规模做合理的预估, 然后对关键的数据做采样, 做对比, 看和自己的预估是否一致, 误差大在什么地方, 是预估的不对, 还是系统实现有问题.
策划对某游戏服务器的要求是3000到5000人在线.
大概的估算
玩了玩游戏, 在前期任务的流程中, 客户端对服务器发生的有效请求数, 实际上是比较少的. 跑路, 点击NPC, 打怪等等, 每一个状态变化中间需要的时间实际上是比较长的. 所以一秒的请求数应该是在0.5~1.0qps左右.
战斗因为是无目标的ARPG, 一点砍瓜切菜的感觉, 输入大概在1.0~2.0qps, 输出就比较高了, 目测系数有5.0~10.0. 也就是一个请求, 可能对应5-10个返回回来. 而且很有可能会有多个广播包.
移动和普通的MMOG差别不是很大, 只是如果用键盘操作的话, 状态变化会非常频繁; 如果是手机的话, 应该在1.0qps左右, 应该就够了. 唯一需要处理的就是广播系数, 周围的玩家越多, 需要广播的包就越多. 某游戏服务器一个场景大概有40~50人. 目测系数有10.0左右.
还有DB IO, 也需要估算, 因为单次操作比较耗时. 战斗过程中大概率是不需要访问DB的, 移动也是, 只有普通的任务和养成系统对DB写依赖比较高; 然后玩家登陆过程中, 因为游戏内有大量的系统, 可能需要10次load操作. 所以按照以往的经验, 卡牌类型的游戏1.0~2.0qps, 那么这个ARPG游戏服务器可能就0.5~1.0qps的样子.
采集数据
最开始处理的MongoDB的读写数据采样. 按照我们的估算, load一个玩家需要10个DB操作, 一个玩家在线大概只需要0.5~1.0个DB操作. 但是我们用机器人去跑, 发现处理MongoDB读写的队列经常因为过大, 进而系统OOM.
所以, 对已经完成DB操作, 和正在队列中的DB操作进行统计分析, 需要统计的数据:
- 类型(简单标注一下自己是哪个系统的)
- 文件, 行数(进行准确的追踪)
C#有CallerLineNumber, CallerFilePath, 可以方便在编译时期获取类似于C/C 的__FILE__, __LINE__.
下来采集的是客户端的输入, 和发送给客户端的返回.
还有一种采集, 就是内存快照, 可以通过dotMemory来搞, 直接用VS获取内存快照最后会发现看不清楚. dotMemory在这方面做得不错.
处理思路
我在计算机程序设计艺术第一卷这本书里面学到一个东西, 就是时间复杂度和系数. 我们在一般的数据结构或者算法书里面只会看到时间复杂度的大概分析, 不会告诉你准确的公式是什么样子的.
然而, 我们游戏里面需要处理的在线玩家数量所呈现出来的公式, 应该是一次函数:
