CN108377208B - 一种基于协议回放的服务器压力测试方法及装置 - Google Patents

Abstract

本发明提出一种基于协议回放的服务器压力测试方法，包括以下步骤：在真实测试环境进行协议数据收集，其中协议数据包括调用服务器协议时的协议、协议参数、协议时间、玩家id以及开服日期；对收集的协议数据进行分类与整理，采用log按等级、日期对协议数据进行分类与整理；布署一致性的服务器，对分类与整理后的协议数据进行回放，并重新设计测试用例；基于协议回放结果进行压力测试以找出优化和处理问题。还提出了一种基于协议回放的服务器压力测试装置。

Description

一种基于协议回放的服务器压力测试方法及装置

技术领域

本发明涉及计算机系统领域，尤其涉及一种基于协议回放的服务器压力测试方法及装置。

背景技术

现在越来越多的游戏追求多人同时在线，有些游戏甚至把所有的游戏玩家都导入到同一个游戏服里。游戏人多的时候，达到十万、数十万，甚至百万级别的在线率，对服务器造成了巨大的压力，稍有模块消耗过多，就很容易造成瓶颈，这时服务器就需要更多的硬件，甚至增加硬件都不能直接解决服务器压力问题。特别是一些bug，在平时压力小的时候，难以察觉，只有压力大到一定程度才会凸显，这大大增加了测试和技术优化的难度。如何测试与验证服务器的可支撑人数呢？如何更好地保障线上游戏服务器的稳定性呢？

传统的压力测试，是基于客户端与服务器的通讯协议，然后高频调用通讯协议。这种测试有个局限，就是单纯地测试api的调用消耗，和真实的线上环境差别较远。例如：玩家的数据不同，玩家聚集的游戏玩法不同，则api调用的量级也大为不同。本发明提出一种测试方法，在外网玩家真实技术测试时，收集相应的玩家协议数据，进行分析整理，建立测试模块，从多个角度，再对服务器进行压力测试。压力测试与真实环境更加接近，提前发现问题，及早优化，以提高服务器的性能和稳定性。

发明内容

本发明的目的是解决现有技术的不足，提供一种基于协议回放的服务器压力测试方法及装置，通过将真实服务器中玩家过多造成的压力问题回放到测试服务器中，进而提前找到问题并解决问题，大大提升正式运营时服务器执行效率和运行时稳定性的技术效果。

为了实现上述目的，本发明的实施例采用以下的技术方案。

首先，根据本发明的一个方面，提出一种基于无锁队列的消息处理方法，包括以下步骤：在真实测试环境进行协议数据收集，其中协议数据包括调用客户端协议时的协议参数、协议时间、玩家id、玩家等级以及开服日期；采用log按玩家等级、开服日期对收集的协议数据进行分类与整理；布署一致性的服务器，对分类与整理后的协议数据进行回放，并重新设计测试用例；基于协议回放结果进行压力测试以找出优化和处理问题。

进一步地，协议数据收集还包括收集服务器协议部分。

进一步地，在本发明的方法实施例中，对协议进行分类与整理之前，先测试log的文件,在测试log的文件之后，将从log提取每个玩家的协议数据分别写到新的文件，每个玩家对应一个文件，并根据玩家属性或开服日期再次分类，从而创建协议池。

进一步地，协议数据回放包括以下子步骤：

协议数据回放包括以下子步骤：

(a)评估布署的服务器，检查服务器是否适于回放；

(b)根据步骤(a)中结果调整服务器使服务器适于回放；

(c)验证协议的完整性，若不完整则进行补充，补充后对协议进行解释；

(d)按预先确定顺序和时间点触发服务器模块来进行回放。

进一步地，根据本发明的另一个方面，重新设计测试用例采用分别对协议放大或按比例调用方式进行设计。

可替代地，压力测试包括以下子步骤：

(i)执行测试用例，查找协议回放过程中服务器存在的压力问题；

(ii)将查找到的压力问题与预期结果进行比较，若符合预期，则子步骤(i)中压力测试结束，若不符合预期，则基于查找到的压力问题对服务器进行优化和处理；

(iii)将优化和处理后的问题发送至重新设计的测试用例进行重复验证，然后再次基于协议回放对服务器进行压力测试，直到查找到的问题符合预期结果。

在本发明的上述方法实施例中，压力测试整个过程需要多次重复测试，以保证测试结果的准确性。

在本发明的上述方法实施例中，压力测试子步骤(ii)中，若查找到的问题与预期结果相符合，也能够再次发送至重新设计的测试用例进行重复验证。

其次，本发明还提出基于协议回放的服务器压力测试装置，包括以下模块：

协议收集模块，用于收集调用服务器协议时的协议数据，协议数据包括协议参数、协议时间、玩家id、玩家等级以及开服日期；

协议整理模块，用于按玩家等级、开服日期对协议数据进行分类与整理；

测试服务器模块，用于对协议数据进行回放，并重新设计测试用例；

结果比较模块，用于将测试服务器测试的结果与预期结果相比较。

本发明的有益效果为：该压力测试用例基于真实的测试环境收集的log数据，再编写测试用例测试，与真正的线上行为更接近。能更准确地验证服务器的压测并查找问题，提前排除服务器的问题，提高游戏正式上线时服务器的稳定性。服务器的稳定，是游戏产品的基本需求，可以为游戏的顺利运营提供保障。

附图说明

图1所示为本发明所公开的基于协议回放的服务器压力测试方法的方法流程图；

图2所示为图1中的协议分类与整理流程图；

图3所示为图2中log对玩家协议按系统的模块分类与整理流程图；

图4所示为图1中协议数据回放流程图；

图5所示为图1中重新设计测试用例的协议放大的其中一个示例图；

图6所示为根据本发明的服务器压力测试方法的一个具体实施例的模拟压测及服务器优化流程图。

具体实施方式

以下将结合实施例和附图对本发明的构思、具体结构及产生的技术效果进行清楚、完整的描述，以充分地理解本发明的目的、方案和效果。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。附图中各处使用的相同的附图标记指示相同或相似的部分。

参照图1所示的方法流程图，在本发明所公开的一个实施例，基于协议回放的服务器压力测试方法，包括以下步骤：在真实测试环境进行协议数据收集，其中协议数据包括调用客户端协议时的协议参数、协议时间、玩家id、玩家等级以及开服日期；采用log按等级、开服日期对收集的协议数据进行分类与整理；布署一致性的服务器，对分类与整理后的协议数据进行回放，并重新设计测试用例；基于协议回放结果进行压力测试以找出优化和处理问题。具体地，协议数据的收集涉及服务器协议数据收集和客户端协议数据收集。服务器协议是指服务器往客户端推送的协议，客户端协议是指客户端发往服务器的协议。同时，“回放”特指将原来在真实测试环境中的运营情况重新在测试服务器进行再现，回放当时的运营状况。具体地，一致性服务器是指真实测试环境中的服务器与回放时所使用的服务器之间的一致性。

由于线上服务器拥堵主要侧重点在于多个玩家的客户端同时向同一服务器发送协议造成的压力，因此本实施例主要收集客户端协议。但是为了测试的完整性和全面性，在测试过程中也可以考虑收集服务器协议数据。

参照图2所示的协议分类与整理流程图，在本发明的一个实施例中，对协议分类与整理之前，还需要编写脚本，测试log的文件。在测试log文件之后，提取每个玩家的协议数据，根据提取的数据进行分类。通常对玩家协议按照玩家等级、日期进行分类。

进一步地，按照玩家等级分类的过程是，先将从log里提取的每个玩家的协议数据分别写到新的文件中，每个玩家对应一个文件，例如player1.log、player2.log......playerN.log等等。然后在该文件的基础上，根据每个玩家所对应的游戏属性，即游戏等级，再次分类：

/level/player_Level_1.log，

/level/player_Level_2.log......

/level/player_Level_N.log。

同样地，按照日期分类的过程也是采用相似的方法，整理玩家协议数据，每个玩家对应一个文件，例如player1.log、player2.log......playerK.log等等。然后在该文件的基础上，根据开服日期再次分类，从开服第1天到第N天：

/date/player_Date_1.log，

/date/player_Date_2.log......

/date/player_Date_N.log。

然后整理上述分类数据创建“协议池”，将所有协议数据全部包含在内。这样在后续步骤进行压测时，可以直接从“协议池”里抽取数据实现协议回放，补充解决了什么问题。

更进一步地，参考图3，还可以采用log对玩家协议按系统的模块进行分类和整理。具体分类与整理过程是，先从log里提取每个玩家每个系统的协议数据，然后一一写到新的文件中，每个系统每个玩家对应一个文件，例如：shop_player1_20171210.log、login_player1_20171210.log....等等。

参考图4所示的协议数据回放流程图，在本发明的一个实施例中，当协议的数据提取好后，下一步是对协议数据进行回放。要想正确回放协议数据，在回放之前还需要布署一致性的服务器。根据上文中对一致性的服务器的解释说明，在布署时，需要满足以下几点：

(1)保证压测服务器的运行环境和测试期间真实服务器的运行环境一致，例如，在测试真实服务器期间开启了部分活动或手动给玩家发送了奖励等，在压测时，也必须执行相同的动作，从而保证不会因环境差异导致结果不同；

(2)考虑到有些运行模块会受到服务器执行的随机数的影响，例如在服务器进行抽奖活动，每次抽奖结果都具备一定随机性。在这种情况下，需要对这些运行模块进行评估，从而协议回放时，服务器判断的条件随之改变。如果这些运行模块的评估结果会给服务器带来巨大的压力差异，则应对服务器微调之后重新判断，并且判断条件相对真实；

(3)调试协议回收时，不可避免地需要封装一些GM，主要是系统提前发放的物品、货币等需要收回；

(4)对收集到的协议的数据进行加工，使其符合压测时服务器端的逻辑。由于客户端发往服务器的协议的正常运行需要依赖前置条件：例如要在客户端登陆后，才可以继续发送其它模块的协议。抑或一个系统的协议有先后顺序。那么我们就需要对协议数据进行加工，补全登陆，同时补全那些一个系统记录的协议不是从头开始的部分，使协议数据完整。最后，需要对协议数据的玩家id等数据进行更改，改成符合服务器需求的玩家id。

布署完成以后，即可对协议数据进行回放，具体回放过程是：

(a)评估布署的服务器，检查服务器中生成的模块是否适于回放，即检验一致性；

(b)根据步骤(a)中的结果适当调整生成的模块或增加GM使服务器适于回放；

(c)验证协议的完整性，若不完整则进行补充，补充后对协议进行解释；

(d)按预先确定顺序和时间点触发服务器模块来进行回放。

进一步地，由于服务器中一套协议是完整存在的，一旦检测到协议不完整，则服务器根据已有的完整协议自动进行补充。在协议正确“回放”之后，还需要重新设计测试用例。压力测试的目的是找出服务器在巨大压力下存在的问题，提前优化和修复。所以测试用例的设计最好也从多个角度进行验证。基于协议收集的数据，重新设计测试用例可以采用分别对协议放大或按比例调用等方式进行设计。具体地，我们可以从以下方面进行设计用例：

(i)以从开始第1天到第N天的协议为基础，分别对协议数据乘以N倍。例如，收集数据过程中第1天有100个玩家和100份协议数据，而模拟时有10000个玩家，则对协议数据放大100倍，将100份协议每份执行100遍，然后服务器进行测试，观察服务器的cpu、内存、硬盘等情况。

(ii)以玩家等级的协议为基础，分别乘以N倍，然后对服务器进行测试，观察服务器的cpu、内存、硬盘等情况。参考图5，图5为玩家等级分布图。在图5中，当玩家等级是1时，服务器人数是568个，那么在设计用例时，将人数乘以N倍，如10倍，那么测试用例中等级为1所对应的玩家则是5680个。

(iii)还可以采用玩家系统协议调用比例设计用例。例如，协议比例：A系统：B系统：C系统＝5:3:2。如果有10000个玩家，则分配：5000个到A系统玩法，3000个到B系统玩法，2000个C系统玩家，以此基础进行协议回放。

需要注意的是，上面几个设计用例只是列举作用，并不意味着我们在设计用例时只有这几个选择。设计用例的目的是尽可能的涵盖所有情况，使得将来系统压测时可以凸显所有的问题。

在本发明的一个实施例中，当用例设计完成之后，接下来就可以开始正式对服务器进行压测了。参考图6，图6所示为根据本发明的服务器压力测试方法的一个具体实施例的模拟压测及服务器优化流程图。具体的压测过程为：

(i)执行测试用例，通过压力测试查找问题；

(ii)将查找到的问题与预期结果进行比较，若符合预期，则该次压力测试结束，若不符合则需对查找的问题进行优化和处理；

(iii)将优化和处理后的问题发送至重新设计的测试用例进行重复验证，然后再次基于协议回放进行压力测试，直到符合预期结果。

进一步地，在上述实施例的基础上，还可以对压测过程做更多的完善。首先，布署与外网(即收集的协议数据来源)性能一致的服务器，提前编写服务器代码及配置，然后注册一批用户验证协议log的有效性。通常情况下，都需要对协议进行加工、调整服务器的逻辑或增加GM。反复调整测试用例参数直到可以执行压测。具体的处理过程为：执行压测，找出服务器中存在的问题，将这些问题与预期结果相比较。若符合预期压力，那么这一轮压测可以结束了。若不符合预期结果，那么还需要对这些问题提早进行优化，在优化完成之后重新发送回测试用例，然后再次进行压测，直至结束。具体的，优化过程包括优化服务器中原有数据库或优化运行代码。

为了保证测试结果的准确性，避免因小概率事件的影响，压力测试过程可以多次重复。同样地，在压力测试子步骤(ii)中，即使查找到的问题与预期结果相符合，也还是可以将该问题重新发送至测试用例重复验证。

在本发明所公开的一个实施例中，提供了一种基于协议回放的服务器压力测试装置，包括：协议收集模块，用于收集调用服务器协议时的协议、协议参数、协议时间、玩家id、玩家等级等协议数据；协议整理模块，用于对玩家协议按等级、日期进行分类与整理；测试服务器模块，用于对协议数据进行回放，并重新设计测试用例；结果比较模块，用于将测试服务器测试的结果与预期结果相比较。

尽管本发明的描述已经相当详尽且特别对几个所述实施例进行了描述，但其并非旨在局限于任何这些细节或实施例或任何特殊实施例，而是应当将其视作是通过参考所附权利要求考虑到现有技术为这些权利要求提供广义的可能性解释，从而有效地涵盖本发明的预定范围。此外，上文以发明人可预见的实施例对本发明进行描述，其目的是为了提供有用的描述，而那些目前尚未预见的对本发明的非实质性改动仍可代表本发明的等效改动。

Claims (9)

1.一种基于协议回放的服务器压力测试方法，其特征在于，包括以下步骤：

在真实测试环境进行协议数据收集，其中协议数据包括调用客户端协议时的协议参数、协议时间、玩家id、玩家等级以及开服日期；

采用log按玩家等级、开服日期对收集的协议数据进行分类与整理；

布署一致性的服务器，对分类与整理后的协议数据进行回放，并重新设计测试用例；

基于协议回放结果进行压力测试以找出优化和处理问题；

其中，所述布署一致性的服务器至少包括以下步骤：

在压测时执行在测试真实服务器期间服务器执行的动作；

对受到服务器执行的随机数影响的运行模块进行评估，根据评估结果对服务器微调；

调试协议回收时，封装一些GM；

对收集到的协议的数据进行加工，使其符合压测时服务器端的逻辑。

2.根据权利要求1所述的服务器压力测试方法，其特征在于，协议数据收集还包括收集服务器协议部分。

3.根据权利要求1所述的服务器压力测试方法，其特征在于，对协议进行分类与整理之前，先测试log的文件,在测试log的文件之后，将从log提取每个玩家的协议数据分别写到新的文件，每个玩家对应一个文件，并根据玩家属性或开服日期再次分类，从而创建协议池。

4.根据权利要求1所述的服务器压力测试方法，其特征在于，协议数据回放包括以下子步骤：

(a)评估布署的服务器，检查服务器是否适于回放；

(b)根据步骤(a)中结果调整服务器使服务器适于回放；

(c)验证协议的完整性，若不完整则进行补充，补充后对协议进行解释；

(d)按预先确定顺序和时间点触发服务器模块来进行回放。

5.根据权利要求1所述的服务器压力测试方法，其特征在于，重新设计测试用例采用分别对协议放大或按比例调用方式进行设计。

6.根据权利要求1所述的服务器压力测试方法，其特征在于，压力测试包括以下子步骤：

(i)执行测试用例，查找协议回放过程中服务器存在的压力问题；

(ii)将查找到的压力问题与预期结果进行比较，若符合预期，则子步骤(i)中压力测试结束，若不符合预期，则基于查找到的压力问题对服务器进行优化和处理；

(iii)将优化和处理后的问题发送至重新设计的测试用例进行重复验证，然后再次基于协议回放对服务器进行压力测试，直到查找到的问题符合预期结果。

7.根据权利要求6所述的服务器压力测试方法，其特征在于，压力测试整个过程需要多次重复测试，以保证测试结果的准确性。

8.根据权利要求6所述的服务器压力测试方法，其特征在于，压力测试子步骤(ii)中，若查找到的问题与预期结果相符合，也能够再次发送至重新设计的测试用例进行重复验证。

9.一种基于协议回放的服务器压力测试装置，其特征在于，包括以下模块：

协议收集模块，用于收集调用服务器协议时的协议数据，协议数据包括协议、协议参数、协议时间、玩家id、玩家等级以及开服日期；

协议整理模块，用于按玩家等级、开服日期对协议数据进行分类与整理；

测试服务器模块，用于对协议数据进行回放，并重新设计测试用例；

结果比较模块，用于将测试服务器测试的结果与预期结果相比较；

其中，测试服务器模块用于布署一致性的服务器，至少执行以下步骤：

在压测时执行在测试真实服务器期间服务器执行的动作；

对受到服务器执行的随机数影响的运行模块进行评估，根据评估结果对服务器微调；

调试协议回收时，封装一些GM；

对收集到的协议的数据进行加工，使其符合压测时服务器端的逻辑。

Images