Jmeter基本使用(性能监控系统实战)

一、Jmeter基本使用(性能监控系统实战)

（1）原生测试报告难以提供实时性，报告中的数据是测试时间段内的平均值，且报告设计可能不够友好。

（2）性能监控平台能实时展示Jmeter压测数据，数据范围可选，界面友好，与原生报告互补，而非取代。

（1）Jmeter：作为压测工具，产生压测数据。

（2）influxDB：开源时序数据库，适合处理资源监控数据，存储压测数据。

（3）Grafana：用于度量分析与可视化图表展示，支持不同数据源，将influxDB中的数据以图表形式展示。

（2）下载对应docker镜像，启动container实例。

（3）监控平台启动：127.0.0.1:3000/

（4）运行Jmeter脚本，查看监控数据，包括压测目标、运行验证、监控环境验证和压力测试实施。

（1）缺点：手动逐步加压，烦琐且耗时。

（2）优点：程序自动执行压测策略，自动等待，完成后自动生成报告，提高效率。

（1）使用Jmeter脚本（.jmx文件）控制压测逻辑。

（3）利用Linux三剑客动态调整并发数。

（4）Jmeter静默运行，脱离UI限制。

静默压测，通过命令行运行Jmeter，更易控制和执行复杂任务。

（1）实施静默压测后，通过命令生成HTML压测报告。

五、自动化压测流程图与脚本编写

（1）脚本存放位置：jmx/auto_stress_emenu.sh

通过自动化压测收集的数据生成详细报告。

（3）Jmeter静默压测与报告生成。

（1）部署位置根据实际需求，可选服务器或本地。

（2）发压程序与被压程序应运行在不同机器上，确保测试环境的独立性。

（2）单个并发数的压测持续时间。

（3）注意事项：高并发下错误率偏高时，可尝试降低并发数。

疑问：性能基线制定与异步接口性能测试？

（1）性能基线制定考虑业务实际需求。

（2）异步接口性能测试主要关注服务器性能。

二、Jmeter性能压测 —— 高并发思路

测试场景：模拟双11，百万级的订单量进行物流信息查询接口的性能测试。

目标：接口响应时间需控制在150毫秒以内，实现每秒10万并发量。

①设定并发量为10万次每秒，由架构师和技术负责人提供。

②使用20台配置为4G内存、4核处理器的机器。

①多数公司无法在测试环境达到与生产环境相同配置。通过基准测试，使用少量请求进行性能测试，推导出生产环境的性能指标。

②假设1台配置相同的机器能完成5000/s并发量的性能指标，通过理论推导得知，只需要1台与服务器相同配置的机器即可完成5000/s并发量，类似数学中的同理可得。

确保性能测试项目部署的服务器硬件型号与生产环境一致。

①生产环境并发量为100000，服务器20台，平均到每台服务器5000/s。当并发需求达到5000/s时，需确保并发量大于等于5000/s才能承受。

吞吐量（接受发送）：≥5000/S（查询数据场景：一秒内处理查询请求数量；多个操作/设计数据修改的请求）

并发量：5000/s(相对并发：某一个时间段；绝对并发：同一个时间)

响应时间：接口请求从开始到结束完整时间-- 150ms

性能测试用例--执行步骤+执行结果验证

不断加大并发--直到系统不满足性能需求【性能瓶颈】【拐点】

压力测试（稳定性测试）--极限并发情况下，系统能否稳定指定时间（一般压力测试时间大于12小时）

测试顺序：先做压力测试再做负载测试，以便确定极限并发并进行负载测试。

模拟总共500线程-->慢慢增加--最终达到

只压500线程而不是5000线程的原因是，接口平均访问返回时间为100ms，1秒就有1个线程可以造成10并发的压力。因此，只需要500个用户，1秒就能达到5000并发的压力。

① Stepping Thread Group，梯度压测，每次递增可以在Next，add中自定义参数。

② Jmeter压测实时仪表盘在后端监听器中。Grafana（未深入研究，待接口框架完成后再继续完善）

③性能测试仪表盘的好处是具有集群监测功能，可以进行linux集群监控。

最后，感谢每一位认真阅读文章的读者，关注、转发、点赞等互动方式在此省略。更多技术交流、资源共享请参考技术交流群。群内提供免费资料，涵盖软件测试面试题库，包含基础理论、功能测试、网络、数据库等多方面内容。希望对大家有所帮助！

三、性能测试监控建模之搭建Prometheus+Grafana监控平台

前言

先提一个问题:"性能测试是否真的很在意有性能监控平台？"

先提一个问题:"性能测试是否真的很在意有性能监控平台？"

服务器资源监控、性能测试指标监控，哪个更在乎？

第一：为弥补jmeter性能测试工具对报表输出方面的不足，如使用类似Loadrunner性能测试工具能提供丰富的报表输出，那么也不需要如此大费周章。

第二：秀儿，锦上添花，初中级性能测试工程师又需要这样的辅助技能展示自己拥有完整的性能测试技能。

jmeter本身是100%纯java开发的GUI工具；正如启动jmeter时提示的一样，如果执行性能测试，建议使用NoGUI模式，即通过CLI模式执行脚本。

为弥补jmeter报告方面输出的不足，它有丰富的插件来完成服务器资源的监控及性能测试指标监控，如<influxdb、prometheus>+Grafana等解决方案；

如果不是这些插件又如何来使用jmeter做性能测试？这就需要性能测试工程师拥有过硬的技术功底：了解系统架构、服务架构、各框架特性及性能调优。

第一：GUI模式下调试脚本，并不适合执行性能测试；为了避免由测试工具带来的性能问题，一般会使用NoGUI模式命令：jmeter-n-txxx.jtl-lxxx.jtl-oreport

第二：CLI模式并没错，但是会有一个问题：随着性能测试持续时间拉长，生成html报告过程中会占用负载机系统资源，而且可能使测试中断或报告无法正常生成；

第三：不管是jtl文件过大无法生成报告，还是输出report失败，都存在不确定性因素；那么我们只能使用linux命令去监控服务器资源：top、vmstat、free、iostat等。

第四：在linux方面除了命令，同样也可以使用nmon工具收集系统资源并download到本地使用excel以及结合执行jmeter测试脚本过程中的性能测试结果进行分析；

第五：那么对Vuser、RT、TPS/QPS等性性能指标如何监控呢？在使用jmeter时，可以通过修改配置文件来改变jtl文件保存结果，一来结果文件大小可以控制，二是方便结合服务器资源数据进行性能分析。

为什么原理要夹在中间阐述?No，这只是补充!!!

原来使用jmeter完成性能测试，一是使用监控插件、二是登录linux服务器实时监控，对于数据持久化来说，是不利的，也就是说，性能测试一旦停止，

环境一恢复，那么无从结合jmeter产生的结果报告进行及时分析，所以需要搭建一款可视化性能监控平台，并且数据持久化；方便事后对比分析。

之前已经有过一篇《搭建JMeter+Grafana+Influxdb+Telegraf性能测试环境监控平台》，都是基于二进制安装包完成；

综上所述，才有今日一篇docker容器部署方案：

不管jmeter搭载何种实时数据库上报数据<prometheus/ifluxdb>，都只是为了服务性能测试找到系统瓶颈。

访问地址：；内容如下：

3、启动prometheus前配置：mkdir/data/prometheus&&vim/data/prometheus/prometheus.yml

时序数据库，搜集由其他服务上报的监控数据

访问地址：

Grafana可以添加prometheus、influxdb、mysql等数据库资源

访问地址：

5、Grafana添加数据源、创建报表，模版地址：grafana.com/grafana/dashboards；可以导入想要的模版

最难的是创建报表，需要数据时序数据库的字段及sql方法，最好还是找模板，省时省力！

6、jmeter开发性能测试脚本，添加listener监听器，别人有做好一个jmeterMonitor：github.com/Germey/JMeterMonitor

jmeter-prometheus-plugin插件原理：将jmeter变成一个DataExporter供prometheus抓取；

运行它的容器，将脚本放在对应宿主机映射卷，启动容器时会执行该脚本，实时上报prometheus

7、关于jmeter-prometheus-plugin插件：github.com/johrstrom/jmeter-prometheus-plugin

可以clone代码，修改监听服务端口啊、服务地址，然后再打包:mvncleanpackage-Dmaven.test.skip=true