1、通过一轮的服务器性能测试，有些心得，总结一下分享给大家，有什么错误或者建议，请指出。针对当前游戏的架构，要开展性能测试，就需要先分析当前架构下，预计会出现哪些性能风险，服务器端和客户端分开进行分析。服务器端：内存消耗、Cpu 占用、登陆压力、单服承载、同屏承载、同地图承载、带宽客户端：流量、帧数（FPS） 、内存消耗、Cpu 占用、流畅度一.服务器端服务器端采用的是多线程，分为逻辑线程和网络线程，分开分析：1.逻辑线程：假设服务器设定每个心跳耗时 200 毫秒，即 1 秒 5 个心跳，这是一个固定值。一个心跳循叫一帧，如果某帧需要处理时间为 100 毫秒，那么服务器就有 50%的空闲时间；再如
2、果某帧需要处理 200 毫秒，那么该线程的 cpu 占用则为 100%。也就是说，如果服务器一帧需要的处理时间为 5 秒钟，那么客户端发送过来的请求经过处理后收到反馈需要的时间为（5 秒+消息在网络上来回消耗），即传说中的服务器卡。那么，要验证逻辑线程卡不卡，或者要找出某负载下逻辑线程卡的原因，则需要记录各种逻辑处理所消耗的时间。目前服务器逻辑消耗主要在玩家和怪物逻辑上，因而需要记录的数据有怪物数量、总逻辑耗时、怪物逻辑耗时、玩家逻辑耗时和其他逻辑耗时。设计用例时则需要考虑不同负载下和无人空跑时的以上耗时的数据采集。采集到这些数据后，可以得出逻辑线程 cpu 占用，怪物耗时占用百分比，玩家耗时
3、占用百分比，并进行分析，如果发现怪物耗时过多，则可以通过增加怪物休眠功能、减少怪物巡逻频率、减少怪物数量等方式来降低消耗；如果发现玩家耗时过多，则需要分析是哪一块玩家逻辑导致，必要时可以增加细分的玩家耗时 log 来获取数据进行分析。2.网络线程：假设 1 个角色每秒产生的消息条数为 a 条，那么 X 个角色同时在线的话，产生的总消息条数 Y 大概为：Y=a*x ；而每个角色产生的 a 条消息，又分为需要广播和不需要广播的。需要广播的消息在处理后放大 n 倍，如移动消息，处理完毕后需要同步给周围的角色，如果周围有 m 个角色的话，消息条数就由 1m，最极端的情况为消息需要同步给全服角色，消息条
4、数会由 1X；又如私聊消息是一对一，因为不需要广播，所以处理完毕后就不会使信息量放大；最极端的情况，全服的全部角色产生的消息都是需要全服广播的，比如全部玩家都在世界频道喊话，那么产生的消息量为 Y=a*X*X。那么，要验证网络线程卡不卡，或者要找出某负载下网络线程卡的原因，则需要记录各个消息在一定时间内一定负载下的发起数量、分发数量；网络线程耗时、各种消息单种的总耗时、耗时均值、峰值；消息是否为同步消息；另外我们还可以记录当前服务器消息堆积数，以及堆积的消息种类和数量。通过这些数据，我们可以得出网络线程 cpu 占用百分比，同步消息的平均同步次数；全部消息中，同步给全服的消息、同步给周围的消息
5、、不需要同步的消息占整体消息百分比；通过这些数据，我们可以哪些消息导致瓶颈，哪些问题导致消息量过大等；通过平均同步次数，可以得出同屏人数瓶颈、同地图人数瓶颈等；通过不同负载下的数据，还可以得出性能数据趋势，也就是说可以通过 500 人数压力的负载得出的数据，推断出 700、1000 人数负载下的性能数据；同时，我们还可以通过采集到的数据，分析哪些消息耗时高，哪些消息数量大。得出以上结论后，就可以有依据有针对性的进行相关优化。举例：服务器在 300 机器人全部世界聊天时，网络线程耗时过高，消息响应延迟非常严重，但是服务器采集到的消息堆积数为 0，也就是说无消息堆积。分析：问题肯定是出在网络线程，
6、通过代码分析，发现服务器全部接收了全部消息，所以消息没有堆积，但是服务器接收了消息后，无法全部快速处理完，所以导致了消息响应延迟严重，就像是部门经理把手头的 100 个任务全部丢给 1 个人处理，经理手头是没有任务堆积，但是那个手下由于无法快速处理完这些任务，导致任务响应很慢。进一步分析，发现消息主要耗时分 2 块：网络库消息的发送和服务器对消息的处理，比例为 7:3。问题找到了，负责网络库的研究网络库的性能，负责服务器的程序找出对应瓶颈。也可以采用另一种方案，那就是限制全服同步的消息的产生，只不过这个只是一个迫不得已的方案而已3.接下来分析内存风险，以现在的配置，服务器内存占用的多少不用过多
7、考虑，主要要考虑的是内存泄露，主要通过查看一点压力下运行一段时间的内存变化情况来检查4.服务器带宽的评估，可以通过记录每个一段时间内收到和发送给客户端的数据包大小和数量来计算出每秒的数据量，然后换算出需要的带宽。bps：byte per second。需要分析的是每秒 byte 数，现有网络，1m 的带宽（单位是 bit） ，带宽数值跟流量的比例理论上为：流量=带宽/8 ，加上损耗，能到达的最大流量大概为 100K5.最后一个登陆压力，主要是验证登陆系统对于大量登陆请求的响应情况。当前情况下不用考虑，因为有已经运营的产品在验证。如果考虑这方面的性能测试的话，应该从一定负载下登陆系统的响应情况来
8、考虑，比如 100/500/1000 机器人批量账号验证、批量创建角色、批量登陆游戏，采集这些数据进行分析。6.总结，通过前面 5 个步骤的分析，对于前面提到的服务器端性能风险，都已经覆盖到了，剩下的就是根据这些分析设计性能测试用例了二.客户端：流量：可以通过服务器端带宽分析得到的数据除以当前服务器人数得出单个客户端的流量帧数（FPS ）：每秒钟帧数，这个可以直接在客户端增加 log 获得内存消耗：查看客户端内存和虚拟内存占用，重点关注是否内存泄露Cpu 占用：直接在任务管理器查看流畅度：分为客户端本身渲染是否流畅和发送给服务器的请求的响应是否流畅。本身的流畅度可以通过增加渲染元素（特效、模型
9、等，还有就是周围玩家数）来确定问题所在或者瓶颈，服务器的响应问题是服务器端优化范畴，上面已经分析分析结果示例：第四组：共 1 组数据，297-336 人，共 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%占 cpu
10、4.7%，同步给周围的 87.04%占cpu32.25%，同步给世界范围的 0.26%E. 怪物数 2470采集的数据示例在线数、数据量和消息耗时等，在一个文档里输出：#*在线玩家： 283 个 最大： 286 个 道具数： 67网络处理耗时： 363620 微秒 最大： 2183180 微秒 怪物数： 2544玩家处理耗时： 0 微秒 最大： 0 微秒 副本数 3怪物处理耗时： 113687 微秒 最大： 155344 微秒 地图数： 34队伍处理耗时： 24471 微秒 最大： 28263 微秒 公会数： 8副本处理耗时： 0 微秒 最大： 0 微秒 队伍数： 17事件处理耗时： 8277
11、 微秒 最大： 17958 微秒公会处理耗时： 60 微秒 最大： 74 微秒管理包(收)： 19250 个 1716911KB 管理包(发)： 1764 个 1392KB客户包(收)： 1302322 个 24670936KB 客户包(发)： 2458001 个 102008KB【协议号 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网络处理耗时(微秒) ： 127098
