游戏上线前服务器应该如何测试

又一款游戏项目上线测试了，深刻体会到服务端在上线前的这段日子是比较“难熬”的。因为除了原有的开发任务，还有大量的第三方接口支持、统计支持、日志分析需求等，以及服务器各种测试和后续测试BUG的排除。其中测试关系到后续服务器能否满足要求稳定运行，马虎不得。

写这篇文章的目的主要是记录一下上线前服务器测试的个人经验，如果觉得内容有不妥或者遗漏的地方欢迎交流。

测试目的

测试不是盲目的，不要为了应付而测试。简单来说测试有以下目的：

• 检测是否满足运营/商务需求；怎么理解？比如游戏上线第一天通过平台/渠道买10W的量，可以假设这10W的量在1个小时之内进来，那么登录/创角大概在1666次/秒，系统能否正常承载？
• 高压力下发现系统瓶颈；
• 高压力下发现功能BUG；
• 得到系统承载数据，为后面可能存在的重构做数据支持；
• 需要发报告，为了应付；

怎么测试

首先我们看看测试需要统计的数据：

[TPS（Transaction Per Second）]，[对应进程CPU占比，内存占用，带宽占用]，[消息处理最大响应时间，最小响应时间，平均响应时间，整体成功率]

测前准备：

• 用户登录；

• 用户登录后，模拟重要协议并间隔发送心跳；

• 用户离线；

这里啰嗦两句何为重要协议，简单的一句话概括： 涉及消费、核心功能的协议 。如果有可能尽量覆盖到网络小包到网络大包。

测试方法：

不断的增加客户端机器人数量，可以得到TPS与响应时间的曲线，可以找到最稳定时最大TPS与最小响应时间。

一般来说TPS与响应时间的关联曲线类似下面：

通过不断的增加请求数，CPU利用率维持在80%附近，成功率能保持在99.9+%时，找到TPS与响应时间的最优值。建议在最优点的情况下，测试机能跑满半天甚至一天时间观察稳定性。

额外的工作：

观察一下机器IO，理论上来说游戏服务器硬盘、内存、网络IO不会成为瓶颈（如果使用云服务器，需要注意下公网带宽）；

观察一下存储的稳定性与时延，就现在流行的mysql、redis来说，虽然官方有完备的benchmark可以作为数据参考，同时云服务也能提供完整的高可用服务（主备或者cluster），但是依旧需要排除滥用/误用的可能；

分析测试数据

拿到测试结果后，结果可能会出现问题的几个点：

1、TPS低

这个问题需要综合分析，一般来说这种情况平均响应时间会偏高：

首先确定机器资源和测试结果的合理性，配置越高的服务器TPS测试结果越高；

然后查看一下CPU是否利用完全了；

如果有缓存队列，观察一下队列长度，作为参考数据；

最后从接入层->业务层->存储层递进式的分析响应时间，找到耗时最多/不合理的那个点；

2、CPU负载正常，成功率低

在CPU负载正常的情况下，可能存在隐藏BUG，需要重视！

3、最大响应时间数值分布偏高

查看是否CPU存在毛刺，排查一下业务是否有高负载周期逻辑或者开发语言上的GC；若没有，想办法拆分定位到具体模块，可能是部分模块不稳定导致。

4、内存占用偏高

估算一下是否合理，不合理则存在内存泄漏。

最后一些个人建议

• 游戏服务器都会由一个有经验的主程来选择服务器框架，这些框架一般都是有过成功产品，官网有benchmark可以参考，所以在其性能和稳定上不用担心太多。在有条件和时间的前提下，建议在游戏开发中期进行一轮轻量测试。因为这个时候，系统整体已经完备，模块与模块之间也相互建立联系，此时测试有助于发现问题，及早修正甚至重构。
• 请重视每一个请求失败，找到原因并分析，每个失败通常会有潜在BUG。
• 如果是分布式架构，那么至少要准备两台机器测试，整个分布式框架流程需要覆盖到。
• 大厂虽然有测试小伙伴可以帮忙，但是还是建议自己搞一搞测试，测试也是对系统感知的一个过程，这个过程稳不稳，有没有犄角旮旯的异常最好切身体会。

（全文结束）

转载文章请注明出处：漫漫路 - lanindex.com