本篇文章给大家谈谈cjava游戏服务器性能测试，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
1、游戏后台怎么做性能测试2、对于c/s架构的游戏 如何测试性能3、游戏上线前服务器压力测试应该怎么做
游戏后台怎么做性能测试
一、什么是游戏后台性能测试
性能（performance）：是系统实现其功能的能力。例如，响应时间、吞吐能力、事务处理数。
性能测试，是指在特定负载情况下，确定系统的响应速度和稳定性的表现。它也可以研究、测量、验证系统的其他特征，比如可扩展性、可靠性和资源使用率。通俗的讲：通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生成性能要求，即在特定的运行条件下验证系统的能力状况。
按游戏构成特点，将性能测试分为客户端性能、服务器性能两大块。楼主问的应该是服务器性能测试吧！
二、性能测试的关键指标
客户端性能的关键指标有：
CPU占用率、内存占用率、流量耗用量、FPS（每秒传输帧数）
服务器端性能的关键指标有：
响应时间、并发用户数、吞吐量等；
三、如何做性能测试
1. 明确测试目标；了解性能测试需求；
2. 编写性能测试计划；
3. 分析性能测试需求；
4. 编写性能测试方案、设计测试场景；
5. 相关资源准备(人力资源、硬件资源、软件资源)；
6. 测试程序开发；脚本维护、测试数据准备、测试监控准备；
7. 执行性能测试并收集测试结果；
8. 分析结果；
9. 系统调优及再测试；
针对楼主的问题，推荐你一个服务器压测平台
WeTest性能测试（腾讯游戏官方出品）
腾讯WeTest压测大师支持的性能测试方法
接口测试
接口的性能评估，给整体做参考
场景测试
登入场景，战斗场景。游戏关键性的业务测试
容量测试
用于评估服务器可承载能力，给上线需要的硬件数量配备做参考
稳定性测试
用于验证服务器长期运行的状况
调优
性能瓶颈分析，定位，系统优化
希望能帮助到你
对于c/s架构的游戏 如何测试性能
很多人关心LR在C/S架构上如何实施性能测试，我想根本原因在于两个方面，一是很多时候脚本无法录制，即LR无法成功调用被测的应用程序，二是测试脚本即使录制下来，可读性不强，往往不能运行通过，调试时无从下手，像音视频、电子地图类的测试差不多也是这个问题。
根据我以往的项目经验，LR是可以做到的，因为它提供了Windows Sockets协议，解决方案实施起来简单但需要足够的细心以及一定的判断力、想象力，可参考如下步骤进行：
1、通过抓包工具捕捉客户端与服务器之间的所有通讯。
关键点：IP过滤，端口过滤，报文类型过滤
目的：弄清楚业务操作过程中，客户端向服务器提交的请求原型，以及服务器对我们请求所做的正确响应
2、将过滤后的报文整理成测试脚本。
关键点：Socket的建立与关闭，send buf的整理，receive buf的整理
目的：将抓包获得的报文转成LR测试脚本（提示：选取合适的抓包工具，使得报文能被保存成文档格式；开发小工具，通过报文中的各个关键字抽取报文中 Data Area中的部分作为buf 区的内容，根据IP字段，端口号等特征完成lrs_send,lrs_receive语句的填写。这部分看上去挺难，但只要对报文做好分析，把握规律，编程的事随便拉个开发都可以轻松搞定）
3、调试脚本
关键点：定位错误，添加校验点
目的：使脚本真正可以拿来进行压力测试
这是最难的一个环节，耐心、细心、判断力都体现在此处。每个人处理问题的方式的不同，我只能提供自己的一点经验。
将脚本RUN-TIME SETTINGS中的扩展日志全部打上钩，并且将脚本拿到controller中单用户执行，注意设置好日志路径。
脚本出错后，用EDIT PLUS或其他的文本工具打开log,找到出错行，然后向上逐一对比服务器返回的数据与录制过程中抓包获得的报文。
在这里，我用了一个小技巧，生成buf内容时，使buf的编号与该buf在抓包获得的报文中编号保持一致，比较起来很方便。
如果服务器返回的buf与抓包时的原始数据一致，自然表示该步骤回放成功，如果不一样，则需要具体情况具体对待。就我的经验来说，往往是因为数据唯一性问题或者是关联的问题造成某一步骤返回的BUF为0或-1，从而导致最终脚本失败。
找到第一个出错的地方后，参数化，关联等手段都可以用上了，这里可能需要重复两次抓包过程，先行比较自己发送的报文是否有区别。
总体思路便是如此，写了一堆，也不知道对大家是否有帮助，对于此类问题，网络上的协助很难派上用场，事情还是要在现场才有可能得到解决啊。本来有意将这东西工具化，甚至产品化，但几个项目实施下来发现变数较多，特别是最后一个环节，完全依赖于测试工程师的自身能力，只好就此作罢
游戏上线前服务器压力测试应该怎么做
对于游戏后台性能，评测标准不只单单是TPS（每秒处理多少个XX请求），因为当你的游戏服务器上线后，不存在一群玩家只发XX请求的压力场景。所以，游戏后台受到的现网请求压力永远是多场景混合的，在这样的压力下，后台能支撑多少人同时在线，才是一个游戏压测者需要得到的有价值的测试结论。
要得到可支撑的”最大同时在线人数”，主要做好2件事：
1、设计你的类现网压力模型
在现网真实压力里，不论压力大小如何变化，现网环境如何变化，一个游戏类型和玩法设计定型后，永远有2个压力宏观数据保持不变：a. 各接口的压力比例不变， b.玩家平均每分钟操作频率不变。因此，压力测试目标就转变成了如何模拟符合ab数据的压力。
对于a，首先从同类型游戏或者本游戏内测阶段，日志插桩，收集各个接口的调用比例；然后，将接口比例转化为场景比例，如同时会有个2%完结登陆、15%玩家战斗、20%玩家拉取好友列表、10%玩家赌博（一个手游场景例子）。
对于b，同样在内测阶段收集玩家平均操作频率。
此时有了a和b，就可以构造出一分钟内玩家同时在线的真实压力模型了。
2、用压测工具构造出符合压力模型的压力
这个可以自己写，也可以使用现成的压测工具。现在市面上的压测工具很多，但很多都是专注于TPS这个参数，不符合游戏行业压测的关注点，同时在线人数。
cjava游戏服务器性能测试的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于、cjava游戏服务器性能测试的信息别忘了在本站进行查找喔。
微信扫一扫 
支付宝扫一扫 
