基于jmeter的服务端性能测试-neil.ppt

  1. 1、本文档共10页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
基于jmeter的服务端性能测试-neil

基于jmeter的服务端性能测试 作者:杨康 时间:2015-08-19 地点:1607 目录 2015 1 2 3 (why)目的 (how)实施 (when)时机 目的 1、最直接的目的: 公司要求不进行压测不允许上线,所以为了通过公司要求是第一个目的 2、最终目的: 为了保证游戏上线后服务器稳定运行 时机 1、产品提测的时机: 因为有些产品不太清楚,所以我们测试有必须提醒下: 1)功能测试已完成,没有重大功能模块变动 2)压测服已申请并布置完毕 2、开始测试的时机: 1)已经收到产品的提测邮件(产品主动或者测试与产品沟通) 2)确保需要的文档、工具已获取 3)确保压测服已布置完成,且接口反馈正确 4)确保压测监控平台zabbix已布置且监控数据与需求一致 实施 1、跟产品确认是进行单接口测试,还是混合接口测试,确定好测试场景 2、确认所有接口的返回结果是否符合预期 实施 3、估算总的请求量n=预期在线人数*预估该接口每天的使用次数 1)总的请求量直接相关的就是测试时间,请求量多测试时间就长 2)测试时间过短达不到测试效果,测试时间过长不利于快速定位、复验问题,故要定一个比较合适的时间来兼顾效率和测试质量 3)这个计算方式只是我的一点经验,不一定对,大家可以自行选择自己的计算方式 实施 4、针对单个场景,设置不同线程数、循环次数进行试探,如下: 1、n/1 10、n/10 20、n/20 ………… 5、通过tps曲线、CPU、内存、DB select等参数的变化来确定一个最佳的线程数和循环次数,标准为tps平稳、CPU占用小于70%、CPU负载小于10、DB的select小于500等等,具体可以跟运维同事商量 实施 6、统计最佳的线程数和循环次数的情况下得到tps、响应时间、cpu、内存、流量等数据,输出测试报告 实施 7、最后对单接口测试具体操作过程进行简单演示: 1)使用单请求验证响应结果是否符合预期 2)设定好线程数、循环数、结果保存路径等来确定一个完整的脚本 3)将脚本上传到linux客户机上 4)运行脚本: “./jmeter -n -t 文件名.jmx” 5)将生成的结果下载到本地,并使用jmeter进行查看 6)统计zabbix监控数据就不演示了,需要运维人员配置 答疑时间 分享结束,谢谢大家,请大家提出宝贵的意见和建议吧~ * * * * * * * * * * * * * *

文档评论(0)

整理王 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档