基于 Jmeter 的百万级 tps 性能测试实践

​如何对系统的承载能力和响应时间做出准确的评估，为资源的合理配置及优化提供依据，性能测试就成了必不可少的测试手段，本文会给读者推荐一款业界占有率最高的一款性能测试工具——Jmeter。

本文作者朱凯是环信测试主管，有近 20 年测试工作经验，服务过多种行业领域。擅长性能测试，有多个大型项目的性能测试经验。

互联网时代，因为超过系统承载能力而出现的宕机情况，时有发生，不仅给用户带来极为不好的体验，也让互联网厂商蒙受了巨大的损失。

根据 Aberdeen Group 的研究报告，对于 Web 网站，1 秒的页面加载延迟相当于少了 11%的 PV(page view 打开页面的次数),相当于降低了 16%的顾客满意度。

Compuware 公司分析了超过 150 个网站和 150 万个浏览页面，发现页面响应时间从 2 秒增长到 10 秒，会导致 38%的页面浏览放弃率。

如何对系统的承载能力和响应时间做出准确的评估，为资源的合理配置及优化提供依据，性能测试就成了必不可少的测试手段，本文会给读者推荐一款业界占有率最高的一款性能测试工具——Jmeter。

下面会从成本、报表系统和扩展性三个维度来介绍下业界最高占有率的性能测试工具 Jmeter。

01 成本

费用成本

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

02 报表系统

Jmeter 能生成丰富的 html 格式报表系统，从不同维度对性能测试结果进行分析，以下是部分 Jmeter 报告的示例图。

报告的基本信息，包括执行时间、应用性能指数和请求概要信息等：

统计概要信息，包括请求名、请求数量、成功数量、错误率、平均响应时间、吞吐率（tps）和网络流量等：

错误概要信息，包括错误类型、错误数量、错误类型占比和错误数量百分比等：

Top 5 错误概要信息，包括错误请求名、请求数量、top 5 错误请求类型和 top 5 错误请求数量等：

整个测试运行期间的响应时间图，包括所有请求的响应时间图：

整个测试运行期间的响应时间分布百分比图，包括 P90、P95、P99、Max 和 Min：

整个测试运行期间的活动线程数：

整个测试运行期间的吞吐字节数：

• Jmeter 如需生成报告，需先记录日志文件，此日志通常会非常大，注意将该文件生成到磁盘空间足够的区域。

• Jmeter 生成报告前会在命令执行目录生成一个 temp 文件夹，该文件夹空间占用会非常大，注意在磁盘空间足够的区域执行命令。

03、扩展性

软件扩展性

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 机器。

04、一个小示例

最后，让我们用一个简单的例子来领略 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]