基于Jmeter的百万级tps性能测试实践
Posted 环信即时通讯云
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了基于Jmeter的百万级tps性能测试实践相关的知识,希望对你有一定的参考价值。
【CSDN 编者按】如何对系统的承载能力和响应时间做出准确的评估,为资源的合理配置及优化提供依据,性能测试就成了必不可少的测试手段,本文会给读者推荐一款业界占有率最高的一款性能测试工具——Jmeter。
本文作者朱凯是环信测试主管,有近20年测试工作经验,服务过多种行业领域。擅长性能测试,有多个大型项目的性能测试经验。
作者 | 朱凯
出品 | CSDN(ID:CSDNnews)
互联网时代,因为超过系统承载能力而出现的宕机情况,时有发生,不仅给用户带来极为不好的体验,也让互联网厂商蒙受了巨大的损失。
根据Aberdeen Group的研究报告,对于Web网站,1秒的页面加载延迟相当于少了11%的PV(page view 打开页面的次数),相当于降低了16%的顾客满意度。
Compuware公司分析了超过150个网站和150万个浏览页面,发现页面响应时间从2秒增长到10秒,会导致38%的页面浏览放弃率。
如何对系统的承载能力和响应时间做出准确的评估,为资源的合理配置及优化提供依据,性能测试就成了必不可少的测试手段,本文会给读者推荐一款业界占有率最高的一款性能测试工具——Jmeter。
下面会从成本、报表系统和扩展性三个维度来介绍下业界最高占有率的性能测试工具Jmeter。
成本
费用成本
Jmeter开源,免费,工具费用成本为0。
使用成本
部署成本非常低,仅依赖jdk,jmeter包解压即可使用,真正做到开箱即用。
脚本编写门槛很低,Jmeter有UI操作界面,方便快速,常规场景0代码即可使用。
丰富的组件满足不同的场景需求:
各种好用的函数能让数据生成更加快捷:
广泛的协议支持满足绝大多数性能测试场景:
-
Web - HTTP, HTTPS (Java, NodeJS, php, ASP.NET,...)
-
SOAP / REST Webservices
-
Websocket
-
MQTT
-
XMPP
-
FTP
-
Database via JDBC
-
LDAP
-
Message-oriented Middleware (MOM) via JMS
-
Mail - SMTP(S), POP3(S) and IMAP(S)
-
Native commands or shell scripts
-
TCP
-
Java Objects
报表系统
Jmeter能生成丰富的html格式报表系统,从不同维度对性能测试结果进行分析,以下是部分Jmeter报告的示例图。
报告的基本信息,包括执行时间、应用性能指数和请求概要信息等:
统计概要信息,包括请求名、请求数量、成功数量、错误率、平均响应时间、吞吐率(tps)和网络流量等:
错误概要信息,包括错误类型、错误数量、错误类型占比和错误数量百分比等:
Top 5错误概要信息,包括错误请求名、请求数量、top 5错误请求类型和top 5错误请求数量等:
整个测试运行期间的响应时间图,包括所有请求的响应时间图:
整个测试运行期间的响应时间分布百分比图,包括P90、P95、P99、Max和Min:
整个测试运行期间的活动线程数:
整个测试运行期间的吞吐字节数:
-
Jmeter如需生成报告,需先记录日志文件,此日志通常会非常大,注意将该文件生成到磁盘空间足够的区域。
-
Jmeter生成报告前会在命令执行目录生成一个temp文件夹,该文件夹空间占用会非常大,注意在磁盘空间足够的区域执行命令。
扩展性
软件扩展性
Jmeter本身是100%Java实现,扩展非常方便。可以自己开发各种协议包、逻辑组件等。
另外不得不提的就是Jmeter本身的社区支持,plugins manager,目前已有100+插件,且还在不断快速增加中,插件遍布jmeter的各种组件类型,极大的方便了使用者的快速组合出各种性能测试场景。
plugins manager的安装和使用也非常的容易。从https://jmeter-plugins.org/install/Install/页面下载jmeter-plugins-manager-1.7.jar,放到jmeter的lib/ext目录后重启jmeter,即可从菜单中找到插件中心:
横向扩展性
当我们要进行百万级TPS性能测试时,单个实例难免力不从心,这个时候,Jmeter的分布式测试模式能很好的解决这个问题。Jmeter的分布式工作模式为一master,多slave模式,如下图:
性能测试过程启动后,master机器下发脚本到各slave机,由slave机对目标机器发起请求,如下图:
单个jmeter实例启用的线程数建议1000-2000之间,太多可能会导致jmeter自身性能下降。
-
分布式测试时,脚本由master机器下午到各slave机,所以slave机并不需要放置测试脚本;测试脚本中如果有读取本地csv的动作,会从各slave机本地读取,为了降低部署成本,分布式测试时,不建议有读取本地文件的行为。
-
分布式测试时,在master机器上执行脚本的过程如果中断测试,会导致第二次测试无法连接到slave机器,此情况需要重启所有slave机器。
一个小示例
最后,让我们用一个简单的例子来领略Jmeter构建性能测试方案的快捷性:
1.在Test Plan下添加一个Thread Group并配置好参数
2.在Thread Group下添加HTTP Request并配置好参数
3.在Thread Group下添加HTTP Header Manager并配置好参数
4.在Thread Group下添加View Results Tree和Summary Report并启动测试
5.查看View Results Tree中的详细信息和Summary Report中的汇总信息
GUI模式通常用来创建和调试脚本,正式做性能测试推荐用命令行来测试:jmeter -n -t [jmx file] -l [results file] -e -o [Path to web report folder]
以上是关于基于Jmeter的百万级tps性能测试实践的主要内容,如果未能解决你的问题,请参考以下文章
百万级高并发MongoDB集群性能数十倍提升优化实践(上篇)