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