大量用户登录游戏产生的“洪荒之力”往往会对游戏服务器产生巨大的压力，游戏上线之前对服务器的承载能力做测试是必须要做的事。本文从腾讯游戏服务器性能测试的经历出发，对服务器性能测试的原理、指标和方法进行了介绍，并介绍了内部目前流行的一些工具和使用技巧。

在四年磨一剑的奥运会，要想成功，必须顶住压力，在0.13秒错失400米自由泳金牌之后，孙杨在200米自由泳比赛中后来居上，夺回冠军；傅园慧靠着自己的“洪荒之力”，反复刷新自己的最好成绩。

那么，同样也是多年磨一剑，游戏开发者精心制作的游戏在面对大量用户的“洪荒之力”时，服务器应该怎样顶住压力，高效运转？

先来看看用户的洪荒之力能产生什么样的后果？

1、面对开服压力，服务器宕机

版本上线之后，新的服务器开放或者服务器更新，面对大量玩家的涌入，如果服务器的性能不好，就会发生登录失败的问题。

2、运营期压力，玩家体验损失

服务器的一个外网活动，比如副本双倍掉落，可能就会造成玩家在某个场景堆积，此时副本玩家就会比平时高很多，对于服务器而言副本这个业务请求会产生比平常高很多的压力，就极容易引发相关的性能问题。

据数据公司预测，获得苹果推荐的价值相当于200万美元左右的推广费用。法国工作室Ankama Games研发的游戏Tactile Wars拿到了苹果50多个国家(几乎是所有上线的地区)的首页“最佳新游戏”推荐，而且曾一度达到了美国iPhone免费榜第二名，日均下载量突破25万，而一个月后该游戏在美国的下载排名已经降到了475，并且有持续下滑的趋势。归根结底是因为开发商没有应对大量玩家涌入服务器的准备，服务器卡死、宕机，闪退让玩家失望选择离开。在这之后Ankama花了两个月的时候才优化服务器逐步挽回了局面。

我们团队也曾经接入过一款代理游戏，有百万级的在线人数预估，当时进行了服务器性能测试，测试结果是当时对方的服务器只能承受1500人的同时在线，如果一套服务器只能承载1500个用户，该游戏要上线需要多少服务器？需要1000套，这无疑是一个巨大的浪费。

面对用户的“洪荒之力”，惨痛的经历一次次的发生，外网问题无小事，游戏发行、渠道对服务器承压情况越来越重视，很多都会要求CP提供服务器性能测试报告作为凭据。

然而目前市场上还没有针对游戏的服务器性能检测工具，无论是开源还是商业软件都不能很好的满足游戏的专项测试需求，与此同时受限于开发周期短以及人力的问题，中小型CP往往采取编写模拟机器人进行简单的压测，测试的覆盖面窄，无法保证并发请求，造成潜伏的问题遗漏到线上。

同样是百万级的游戏，有的公司需要上千台服务器，而有的公司只要几百台服务器，巨大的服务器采购运维成本差异皆因各家公司做服务器性能测试乃至性能调优的能力参差不齐。

那么问题就来了，服务器性能测试是什么？要怎么做才最有效呢？

提到服务器性能测试，不得不提到很多术语。为了让大家更容易理解，举个生活中的例子：

你中午去“海底捞”吃饭。

我们可以把“海底捞”这个酒楼看成一个被测系统。

你去吃饭，就是对这个被测系统发起请求，对这个系统造成了一定的负载。你带去的人越多，那么这个餐馆就越繁忙，可以说餐馆承受的负载就越大。

你开始点菜。这个时候你隔壁桌的人也开始点菜。那么你们两个对这个系统产生了并发的请求。同时，其他桌有的在吃菜，有的在等菜，这些都是并发进行的事务。一个完整的吃饭事务可以定义成包括：点菜，下单，上菜，买单四个步骤。对于一个C/S的系统来说，可以对应于：建立连接，发送请求，接受应答，断开连接。

影响一个餐馆生意好坏的一个重要原因是上菜速度。上菜速度体现在两个方面：

1. 一个顾客请求的处理耗时，从下单到上菜中间等待的时间，我们称之为响应时间。

2. 这个餐馆同时为多名顾客上菜的频率，我们称之为吞吐量。

很多因素会影响上菜速度，比如服务员的个数、厨师的个数。对于一个C/S的系统，服务员相当于是接入层，厨师相当于是后台服务。假如服务员太少，下单很慢，后面的厨师都闲着，那么上菜速度也快不了；假如服务员够多，下单足够快，但是厨师太少，下的单来不及做，同样上菜速度也很慢；如果服务员很多，厨师也很多，但是来的客人很少，那么大部分的服务员和厨师都闲着，资源全部浪费掉了。因此，接入层和后台服务进程个数、以及资源配比，都是需要根据实际情况进行调优的。

来多少顾客，这是酒楼自己无法控制的，但是酒楼的上菜速度、餐位多少都会制约客流量。一定有一个峰值客流量，当来的客人超过了这个峰值，那么这些客人就会等位，或者是上菜速度超慢让客人无法容忍。容量测试就是通过工具模拟足够多的顾客来吃饭的事务，希望找到这样一个客流量对酒楼产生一定的负载，这个时候酒楼既能接待最多的客户同时也能保证最短的等待时间。更多的，还可以对这个酒楼人员配置和餐位设置等进行调优，以期达到一个最理想的资源利用率和效率。

客流量跟进来的客人多少有关，也跟餐馆的接待能力有关。单方面增加来就餐的顾客，遭到投诉的可能性就越大，上错菜的可能性也越大。

性能测试的核心概念主要包括两部分：正确的测试方法，正确的评价性能的指标。测试方法会告诉你用什么样的套路去执行测试；性能指标是告诉你如何用数值来描述你的测试对象的性能。

在介绍测试方法之前，先来了解一下关于服务器性能测试的一些指标含义。

• 吞吐量：固定时间间隔内的处理完毕事务个数。通常是1秒内处理完毕的请求个数，单位：事务/秒（tps）。

• 平均吞吐量：一段时间内吞吐量的平均值。无法体现吞吐量的瞬间变化。

• 峰值吞吐量：一段时间内吞吐量的最大值。是用来评估系统容量的重要指标之一。

• 最低吞吐量：一段时间内吞吐量的最小值。如果最小值接近0，说明系统有“卡”的现象。

• 70%的吞吐量集中区间：通过统计15%和85%的吞吐量边界值，计算出70%的吞吐量集中区间。区间越集中，吞吐量越稳定。

• 响应时间：一次事务的处理时间。通常指从一个请求发出，到服务器进行处理后返回，再到接收完毕应答数据的时间间隔，单位：毫秒。

• 平均响应时间：一段时间内响应时间的平均值。无法体现响应时间的波动情况。

• 中间响应时间：一段时间内响应时间的中间值，50%响应时间，有一半的服务器响应时间低于该值而另一半高于该值。

• 90%响应时间：一段时间内90%的事务响应时间比此数值要小。反应总体响应速度，和高于该值的10%超时率。是用来评估系统容量的重要指标之一。

• 最小响应时间：响应时间的最小值。反映服务最快处理能力。

• 最大响应时间：响应时间的最大值。反映服务器最慢处理能力。

• CPU占用率：1-CPU空闲率，表示CPU被使用情况，反映了系统资源利用情况。

关于服务器性能测试，目前常用的测试方法有这些：

1、现网数据预估

现网数据预估是根据压力测试过程中的部分数据，对未来大量用户访问的情况机型预估。图中的横轴代表现网吞吐量，纵轴代表CPU压力。

图中绿色的部分代表当前的服务器压力，当收集一段时间数据之后，可以模拟一条曲线。假设对服务器的上线成本预估是80%，可以通过曲线拟合的方式推测出现网的能力是多少，也从而推断出最大上限是多少。

缺点：通常游戏服务器都是比较复杂的，这种方式只适合简单的服务器拟合，复杂服务器数据就不太准确。

2、真人压测

真人压测就是通过邀请一定数量的真实用户来玩游戏，从而对服务器达到一个测试效果。这种方式他最大特点在于用户的行为相对是最真实的，因为用户的使用完全不会受到限制，和线上一个真实用户一样。目前游戏上线过程中的“封测”，就可以被认为是一种真人压测，可以帮助开发者发现一些性能问题。

但是这种方式也存在着弊端：

• 暴露出的性能问题有限

  许多经过封测的游戏到上线还会产生问题，原因之一就是封测人数通常还是太少，虽然有几百或者几千用户在玩，但是并发并不够，不足以暴露服务端性能问题；

• 不适合调优

  服务器性能测试不光需要暴露服务器的问题，暴露问题之后还需要不断的回归调优，但是真人是无法完全重复这些行为方式的。

3、接口测试

服务器方面的接口测试与传统意义上的接口测试略有不同，当开发人员需要对一套服务器进行评估，但是又时间不足的情况下，我们可以考虑选择一些具有代表性的功能，以及一些高风险功能进行测试，通过以小见大的方式，来评估整套服务器性能。

当然这个方法的主要问题就是无法遍历整个服务器的接口，难以避免一些微小的问题。

4、录制回放

这里面包含两部分，“录制”就是通过抓取数据包的方式，来获取游戏时的协议，比如用户登录游戏时抓取登录包；“回放”即把这些捕获的协议重新发送给服务端，这样理论上就可以通过工具放大协议量级达到性能测试的目的，比如将之前录制的登入协议扩大1w倍给服务器，这样就模拟了1w人同时登入的情况。

这个方法存在的问题是，游戏的协议交互非常复杂，如果只是单纯的放大数据包，对于服务器是产生不了多大的压力的。这类方法比较适合固定输入输出服务类型的测试。

5、机器人模拟

机器人模拟测试是对以上各种测试做了一个平衡， 通过高还原真实玩家的用户行为，模拟高并发场景，从而得到类似很多人同时游戏的测试效果。机器人模拟有三个优势：

高还原游戏玩法，深度模拟真实用户行为：

1.  并发性不受限制，从1W到10W，压力能够自主设置；

2.  可以反复执行，便于性能调优回归；

3.  实现7*24小时不断监控，在开发提交代码之后，版本在自动编译之后就跑新的测试，这样每天都能进行性能监控，在调优方面，完全地进行一个重复性测试，可以不断的进行回归和调优。

这个方法的问题就在于机器人模拟需要专人开发，对测试者的开发能力，分析能力都有一个比较高的要求。

说到这里，我们对之前所有的服务器性能测试方法进行了一个总结：

我们可以发现，速度与准确性始终是对立的，如果游戏开发者队友服务器测试有一个明确的规划，对服务器压测有一定的时间预留，机器人模拟的效果是非常好的。

那么我们到底是如何来开发一款进行服务器性能测试的机器人呢？

整个开发过程主要可以概括为三大步骤，建模， 分析， 开发。

第一步，建模。

建模是什么呢，建模是为了模拟真实玩家行为，分为两种方法：

1）探索典型玩家关键路径

通过大量玩家数据的支撑，选择最多的行为路径，设计机器人模拟的行为。

2）通过封测过程中的运营数据，生成专家视图

这个方法就是通过去测试服中搜集用户的协议数据，并对这些协议数据进行分析，确定各自是什么行为，把用户的这些协议数据还原成为用户行为的操作过程就像是把一块块散乱的拼图重新组织起来一样。

在这个过程中，最简单的是按比例组织，通过数据分析，发现用户登录，战斗各自占据多少比例，以这个比例来分配一定的人数进行登录和战斗。但是这个方式并不太适合游戏，对于游戏本身来说，一百个人不断的重复登录的行为，一百个人同时重复游戏的行为，显然是不符合逻辑的。

那么在分析的过程中，采用概率的方式，是更加贴近一个真实用户的行为的。当模拟一个真实用户登录之后，有一定的可能性会重新登录，还有一部分可能性就进行战斗，例如机器人有10%概率重新登入，50%概率进行战斗。 同时我们还需要考虑对角色身上的装备数据， Cache的命中，数据库容量等等，目的是让机器人更接近真实用户，更加符合一个真实用户的行为。

第二步，分析。

那么我们会对客户端进行行为交互和协议分析。一方面，为后续协议开发实现做准备；另外，在登入的过程中，会产生大量的协议，如果没有对客户端进行分析，可能只是调用了登录的协议，从实际的协议交互上来说，一次登录可能包含了很多其他的协议信息，那这时我们实现登入就不能仅仅是个简单的登录协议，可能还包含拉取邮件信息，拉取好友信息等协议，两者之间对登入的性能差异影响非常大。

第三步，代码开发。

主要包含两部分：

1）协议的开发，包括协议的实现，协议的解包等；

2） 业务逻辑的组织，主要对上述游戏模型进行实现。

不过令人遗憾的是，对于游戏开发者的实际情况来说，充足的测试时间并不是每次都可以保证的，而且对于模拟机器人的开发过程本身又是一个很大的投入，对于一些通用场景，如果能够有通用的平台代码可以调用，相信对于游戏开发者是一种极大的解放。

对于服务器性能测试来说，好的测试要做到这样几点：

• 业务场景模拟。可编码解析任意协议，实现复杂业务场景。

• 发现瓶颈。支持使用场景中复杂的数据传输行为，比如“登录”“查看个人信息”等，更加真实的模拟用户行为，发现服务器问题；

• 持续压力。实现7*24小时一定量级的服务器压力；

• 触达极限。短时间内触达服务器的压力上限。

• 灵活自定义。对于类似游戏的复杂混合场景，可以结合在线代码开发IDE，实现对任何标准或自定义协议的通信。