不管是手游还是端游,针对任何一款游戏做后台性能压测要做的工作是非常多的。首先要做很多准备工作,包括熟悉游戏玩法、熟悉游戏后台架构、熟悉游戏协议、设计压测方案、选择压测工具、部署压测环境、编写压测脚本(包括动态库程序)等。其次就是执行压测,即按照事先设计好的压测方案执行压测,并收集压测结果数据。接着就是分析压测结果数据,并定位性能瓶颈。做完这三步,压测的工作基本上就算完成了。当然,如果要想做的更多,做的更好,那还要做完最后一步,即给出性能优化的解决方案,哈哈,这个恐怕没有多少测试人员去做吧。
受篇幅所限,本文主要讲述其中一个环节,即如何设计压测方案。压测方案的设计是压测流程中非常重要的一个环节,因为压测方案设计的是否合理直接影响到压测结果的有效性。这里所说的有效性是指,根据压测方案执行压测所得到的压测结果是否能够如实的反映出被测服务器的真实性能。
本文讲述的压测方案包含两个个方面的内容:基于玩家游戏模型的压测方案设计、基于游戏后台架构的压测方案设计。
一、 基于玩家游戏模型的压测方案设计
压测的本质就是模拟大量玩家同时在线玩游戏以对游戏后台造成访问压力,从而检验服务器是否满足预期的性能要求。这里所说的玩家游戏模型是指玩家玩游戏的行为模型,玩家玩不同类型的游戏时其游戏行为侧重点是不同的,所以针对不同类型游戏设计的压测方案也是不同的。在这里我们把压测方案概念缩小到压测场景来讲,下面以竞技手游七骑士为例来讲解基于玩家游戏模型的压测场景的设计。
1、【七骑士】压测场景设计
七骑士是一款竞技卡牌类的韩国代理手游,该游戏主要玩法就是英雄养成、英雄组队打副本、英雄组队PK、英雄组队打BOSS,压测时设计的玩家游戏场景主要有以下这些。
二、基于后台架构分析的压测方案设计
然而,仅仅根据玩家游戏模型得到的压测结果是不完整的,或者说这个压测结果还不能完全体现出游戏后台性能。压测环境与线上部署的真实环境是有区别的,受测试资源限制及方便性,压测环境一般都是单机部署,这里的单机部署包含两种情况:一种情况是,游戏后台是单机架构,所有业务逻辑都部署在一台gameserver上面,这种架构多出现在轻度休闲手游里,特别是代理游戏居多。另外一种情况是,游戏后台是多机架构,即不同的业务逻辑部署在不同机器上面,且每种业务只需一台机器(实际线上是多台机器),这种架构多出现在相对重度型的手游里。正是由于压测环境部署的区别,导致压测存在盲点,测试人员如何在环境受限的情况下通过压测反映出服务器的性能概况。下面还是以七骑士为例来讲解基于后台架构分析的压测方案设计方法。
1、七骑士后台架构
架构分析:
七骑士后台由五大模块组成:GameServer、普通聊天服、公会聊天服、cache、DB。除了普通聊天服和公会聊天服作为独立的服务单独部署外,其他所有游戏逻辑功能都包含在GameServer服务器里,GameServer单台物理机部署。REDIS(缓存服务)和DB(Sql Server)也都是单台物理机部署,REDIS的作用主要是提高热点数据访问效率。
这种架构是最简单的架构,即GameServer+数据存储(REDIS和DB),对于这种简单架构的手游,我们一般主要考虑以下三种压测方案:
(1) 综合场景游戏模型压测方案
由于游戏所有逻辑都集中在GameServer里,我们可以通过模拟玩家游戏行为对GameServer进行压测,具体做法就是将玩家游戏场景相关的协议组合起来进行压测。
(2) 单业务可靠性压测
这里主要考虑登录场景的压测和拉取好友排行榜场景的压测,主要是由于这两个场景与第三方(腾讯QQ平台或微信平台)有数据交互,如果游戏内部逻辑处理不当容易出问题,所以需要进行单独压测。
(3) 数据存储性能评估模型的压测
从游戏后台架构图可以看出游戏数据存储有两种方式,一种是REDIS存储,一种是DB存储,压测时必须考虑REDIS和DB是否存在性能瓶颈。
玩家登录后先从DB中读取数据,同时将数据写入REDIS,后面需要继续读取相同的数据就直接从REDIS读取,而不需要从DB读取。玩家有数据更新时,DB和REDIS同时写,之后需要这些数据时,直接从REDIS读取,Redis与DB是无任何交互的。由于是实时写DB,所以DB很可能存在性能瓶颈。
REDIS的存在可以减轻DB的压力,一旦REDIS发生故障,DB会出现突发的压力风险,所以压测时必现考虑到这种可能发生的风险。我们可以模拟服务器有较大访问压力的时候REDIS突然出现故障时DB的性能表现,具体做法就是在综合场景压测的时候,让REDIS机器宕机或网络断开一段时间,观察DB的性能表现,然后再恢复REDIS服务,继续观察DB的性能表现。
目前腾讯WeTest服务器性能测试已经正式对外开放,业务场景模拟,持续压力触达服务器极限,帮助寻找服务器性能问题!点击链接:http://wetest.qq.com/gaps/立即体验!