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

又一款游戏项目上线测试了,深刻体会到服务端在上线前的这段日子是比较“难熬”的。因为除了原有的开发任务,还有大量的第三方接口支持、统计支持、日志分析需求等,以及服务器各种测试和后续测试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

Leave a Comment

Your email address will not be published.