游戏性能测试方案

《游戏性能测试方案》由会员分享，可在线阅读，更多相关《游戏性能测试方案（3页珍藏版）》请在装配图网上搜索。

1、通过一轮的服务器性能测试，有些心得，总结一下分享给大家，有什么错误或者建议，请指出。针对当前游戏的架构，要开展性能测试，就需要先分析当前架构下，预计会出现哪些性能风险，服务器端和客户端分开进行分析。服务器端：内存消耗、Cpu占用、登陆压力、单服承载、同屏承载、同地图承载、带宽客户端：流量、帧数（FPS）、内存消耗、Cpu占用、流畅度一.服务器端服务器端采用的是多线程，分为逻辑线程和网络线程，分开分析：1.逻辑线程：假设服务器设定每个心跳耗时200毫秒，即1秒5个心跳，这是一个固定值。一个心跳循叫一帧，如果某帧需要处理时间为100毫秒，那么服务器就有50%的空闲时间；再如果某帧需要处理200毫秒

2、，那么该线程的cpu占用则为100%。也就是说，如果服务器一帧需要的处理时间为5秒钟，那么客户端发送过来的请求经过处理后收到反馈需要的时间为（5秒+消息在网络上来回消耗），即传说中的服务器卡。那么，要验证逻辑线程卡不卡，或者要找出某负载下逻辑线程卡的原因，则需要记录各种逻辑处理所消耗的时间。目前服务器逻辑消耗主要在玩家和怪物逻辑上，因而需要记录的数据有怪物数量、总逻辑耗时、怪物逻辑耗时、玩家逻辑耗时和其他逻辑耗时。设计用例时则需要考虑不同负载下和无人空跑时的以上耗时的数据采集。采集到这些数据后，可以得出逻辑线程cpu占用，怪物耗时占用百分比，玩家耗时占用百分比，并进行分析，如果发现怪物耗时过多

3、，则可以通过增加怪物休眠功能、减少怪物巡逻频率、减少怪物数量等方式来降低消耗；如果发现玩家耗时过多，则需要分析是哪一块玩家逻辑导致，必要时可以增加细分的玩家耗时log来获取数据进行分析。2.网络线程：假设1个角色每秒产生的消息条数为a条，那么X个角色同时在线的话，产生的总消息条数Y大概为：Y=a*x；而每个角色产生的a条消息，又分为需要广播和不需要广播的。需要广播的消息在处理后放大n倍，如移动消息，处理完毕后需要同步给周围的角色，如果周围有m个角色的话，消息条数就由1m，最极端的情况为消息需要同步给全服角色，消息条数会由1X；又如私聊消息是一对一，因为不需要广播，所以处理完毕后就不会使信息量放

4、大；最极端的情况，全服的全部角色产生的消息都是需要全服广播的，比如全部玩家都在世界频道喊话，那么产生的消息量为Y=a*X*X。那么，要验证网络线程卡不卡，或者要找出某负载下网络线程卡的原因，则需要记录各个消息在一定时间内一定负载下的发起数量、分发数量；网络线程耗时、各种消息单种的总耗时、耗时均值、峰值；消息是否为同步消息；另外我们还可以记录当前服务器消息堆积数，以及堆积的消息种类和数量。通过这些数据，我们可以得出网络线程cpu占用百分比，同步消息的平均同步次数；全部消息中，同步给全服的消息、同步给周围的消息、不需要同步的消息占整体消息百分比；通过这些数据，我们可以哪些消息导致瓶颈，哪些问题导致

5、消息量过大等；通过平均同步次数，可以得出同屏人数瓶颈、同地图人数瓶颈等；通过不同负载下的数据，还可以得出性能数据趋势，也就是说可以通过500人数压力的负载得出的数据，推断出700、1000人数负载下的性能数据；同时，我们还可以通过采集到的数据，分析哪些消息耗时高，哪些消息数量大。得出以上结论后，就可以有依据有针对性的进行相关优化。举例：服务器在300机器人全部世界聊天时，网络线程耗时过高，消息响应延迟非常严重，但是服务器采集到的消息堆积数为0，也就是说无消息堆积。分析：问题肯定是出在网络线程，通过代码分析，发现服务器全部接收了全部消息，所以消息没有堆积，但是服务器接收了消息后，无法全部快速处理

6、完，所以导致了消息响应延迟严重，就像是部门经理把手头的100个任务全部丢给1个人处理，经理手头是没有任务堆积，但是那个手下由于无法快速处理完这些任务，导致任务响应很慢。进一步分析，发现消息主要耗时分2块：网络库消息的发送和服务器对消息的处理，比例为7:3。问题找到了，负责网络库的研究网络库的性能，负责服务器的程序找出对应瓶颈。也可以采用另一种方案，那就是限制全服同步的消息的产生，只不过这个只是一个迫不得已的方案而已3.接下来分析内存风险，以现在的配置，服务器内存占用的多少不用过多考虑，主要要考虑的是内存泄露，主要通过查看一点压力下运行一段时间的内存变化情况来检查4.服务器带宽的评估，可以通过记

7、录每个一段时间内收到和发送给客户端的数据包大小和数量来计算出每秒的数据量，然后换算出需要的带宽。bps：byte per second。需要分析的是每秒byte数，现有网络，1m的带宽（单位是bit），带宽数值跟流量的比例理论上为：流量=带宽/8，加上损耗，能到达的最大流量大概为100K5.最后一个登陆压力，主要是验证登陆系统对于大量登陆请求的响应情况。当前情况下不用考虑，因为有已经运营的产品在验证。如果考虑这方面的性能测试的话，应该从一定负载下登陆系统的响应情况来考虑，比如100/500/1000机器人批量账号验证、批量创建角色、批量登陆游戏，采集这些数据进行分析。6.总结，通过前面5个步骤

8、的分析，对于前面提到的服务器端性能风险，都已经覆盖到了，剩下的就是根据这些分析设计性能测试用例了二.客户端：流量：可以通过服务器端带宽分析得到的数据除以当前服务器人数得出单个客户端的流量帧数（FPS）：每秒钟帧数，这个可以直接在客户端增加log获得内存消耗：查看客户端内存和虚拟内存占用，重点关注是否内存泄露Cpu占用：直接在任务管理器查看流畅度：分为客户端本身渲染是否流畅和发送给服务器的请求的响应是否流畅。本身的流畅度可以通过增加渲染元素（特效、模型等，还有就是周围玩家数）来确定问题所在或者瓶颈，服务器的响应问题是服务器端优化范畴，上面已经分析分析结果示例：第四组：共1组数据，297-336人

9、，共592秒A. 消息。均值370689微秒，cpu占用均值37.06%B. 逻辑。均值147816微秒，cpu占用均值27.88%，总耗时130226423微秒。其中怪物累计耗时107310854微秒占82.4%占cpu22.97%，玩家累计耗时21292940毫秒占16.35%占cpu4.55%，其他累计耗时忽略。C. 同步消息平均同步9.42次D. 消息耗时中，同步给自身的12.68%占cpu4.7%，同步给周围的87.04%占cpu32.25%，同步给世界范围的0.26%E. 怪物数2470采集的数据示例在线数、数据量和消息耗时等，在一个文档里输出：#*在线玩家： 283个 最大： 2

10、86个 道具数： 67网络处理耗时： 363620微秒最大： 2183180微秒怪物数： 2544玩家处理耗时： 0微秒最大： 0微秒副本数 3怪物处理耗时： 113687微秒 最大： 155344微秒地图数： 34队伍处理耗时： 24471微秒 最大： 28263微秒公会数： 8副本处理耗时： 0微秒最大：0微秒队伍数： 17事件处理耗时： 8277微秒最大： 17958微秒公会处理耗时： 60微秒最大：74微秒管理包(收)： 19250个1716911KB管理包(发)： 1764个1392KB客户包(收)： 1302322个24670936KB客户包(发)： 2458001个102008K

11、B【协议号ID】 =ZP_PCMOVE_ASK ,【协议号数量】 =77019 ,【分发数量】=1318707 ,【协议号总耗时】 =70070339 微秒 , 【均值】 = 909 微秒, 【峰值】 =10091 微秒, 【是否同步】 =是怪物累计耗时 ： 106584657玩家累计耗时 ： 17497538其他累计耗时 ： 1111735开始时间：2010-10-22 11:21:26:212结束时间：2010-10-22 11:32:11:087逻辑数据采集：逻辑耗时(微秒) ： 105705逻辑耗时(微秒) ： 126279逻辑耗时(微秒) ： 96004网络数据采集：网络处理耗时(微秒) ： 132952网络处理耗时(微秒) ： 139074网络处理耗时(微秒) ： 1270983 / 3文档可自由编辑打印