目录
- 性能监控平台组成
- 自动化压测
- 压测实施
一、性能监控平台组成
性能监控平台好处
- JMeter原生测试报告带来的“痛苦”
- 不具备实时性
- 报告中的数据是测试时间段内的平均值
- 长相问题
- 性能监控平台的优势
- 实时展示JMeter压测数据
- 数据范围可选
- 界面更友好
JMeter性能监控平台组成
- 参考文章：https://www.jianshu.com/p/476ba7703409
- JMeter：压测工具，产生压测数据
- InfluxDB：开源时序数据库，特别适合用于处理和分析资源监控数据，用于存储压测数据
- Grafana：度量分析与可视化图标展示工具，可以支持不用种类的数据源，用于将存储于InfluxDB中的数据以图表的形式展示出来
JMeter性能监控平台准备
- 部署方法：Docker 部署
-
下载对应docker镜像，启动container实例
image.png - 压测目标：美餐网
- 运行验证数据传递的正确性
- 验证监控环境运行正常
- 调试ok之后再开始实施压力测试
-
Demo：启动性能监控平台组件并验证系统的正确性
image.png -
JMeter添加后端监听器
image.png -
压测后数据监控
image.png
Tips：如果性能监控平台与JMeter报告结果有差异，要以JMeter的结果为准，因为性能监控平台本身也会消耗资源，而且不是实时刷新。
二、自动化压测
- 为啥要自动化压测呢?
- 手动逐步加压
- 需要人肉改并发数，然后等待完成
- 烦!!!!!
- 所以，制定好策略，让程序自动加压，自动等待；完成后坐收报告
- 计算机努力的干活，我去做更重要的事情
- 希望测试生涯由此变得美好一些
实现思路
- JMeter脚本( .jmx文件) - 压测逻辑
- Shell - 控制逻辑
- 不能绕开麻烦，并发数的更改 - 想想Linux的三剑客之一
- JMeter静默运行 - 脱离UI限制，使得自动化运行更稳定
JMeter静默压测
- 静默 -> 脱离UI运行JMeter压测
- 好处：命令运行更容易“搞事情”
- 命令格式：
jmeter -n -t $jmx_file-l $jtl_file - jmx JMeter压测程序脚本文件，压测控制过程记录在jmx文件中
- jtl文件是JMeter压测请求响应数据的原始文件
自动生成Web版压测报告
- 实施静默压测之后，通过命令直接生成对应的html压测报告
- 过程：jfl原始数据 -> html压测报告
- 好处：快捷、省事、节约时间
- 命令格式：
jmeter -g $jtl_file -o $web_report_folder - 可以与静默压测命令整合：
jmeter -n -t $jmx_file -l $jtl_file -o $web_report_folder
程序流程图
image.png
压测脚本
源码解读 - Demo
自动化源码位置：jmx/auto_stress_emenu.sh
-
JMeter中修改并发数为脚本中的变量
image.png 自动化压测脚本 auto_stress_emenu.sh
#!/usr/bin/env bash
# 压测脚本模板中设定的压测时间应为60秒
export jmx_template="emenu"
export suffix=".jmx"
export jmx_template_filename="${jmx_template}${suffix}"
# uname命令可以输出系统名称，MacOS为Darwin，Linux为Linux
export os_type=`uname`
# 需要在系统变量中定义jmeter根目录的位置，如下
# export jmeter_path="/your jmeter path/"
echo "美餐网自动化压测全部开始"
# 压测并发数列表
thread_number_array=(10 20 30 40 50 60 70)
for num in "${thread_number_array[@]}"
do
# 生成对应压测线程的jmx文件
export jmx_filename="${jmx_template}_${num}${suffix}"
export jtl_filename="test_${num}.jtl"
export web_report_path_name="web_${num}"
# 清理环境
rm -f ${jmx_filename} ${jtl_filename}
rm -rf ${web_report_path_name}
cp ${jmx_template_filename} ${jmx_filename}
echo "生成jmx压测脚本 ${jmx_filename}"
# 判断操作系统，如果是Darwin即MacOS系统，否则为Linux系统
if [[ "${os_type}" == "Darwin" ]]; then
sed -i "" "s/thread_num/${num}/g" ${jmx_filename}
else
sed -i "s/thread_num/${num}/g" ${jmx_filename}
fi
# JMeter 静默压测
${jmeter_path}/bin/jmeter -n -t ${jmx_filename} -l ${jtl_filename}
# 生成Web压测报告
${jmeter_path}/bin/jmeter -g ${jtl_filename} -e -o ${web_report_path_name}
done
echo "美餐网自动化压测全部结束"
压测测试
-
终端输入：
sh auto_stress_emenu.sh
image.png -
grafana监控
image.png
查看报告
-
报告路径
image.png -
报告
image.png
image.png
Tips：被压程序和压测脚本运行最好是分别两个主机上，因为JMeter运行也会消耗资源。而且两台主机最好在同一机房内。
三、实施压测
压测实施计划
制定压测策略不同的并发数：10，20，50，100，200，400，.....
单个并发数压测时长：1分钟
参考压测报告，记录结果运行自动压测简化操作
-
测试期望结果
- 验证能够支撑多大并发数，峰值数
- 验证错误率，定义可接受范围，<=0.1% or <=0.5% or must = 0%
-
系统性能点
image.png
压测实施计划
- Demo：运行压测，收集数据
- 并发数设定：10，20，30，40，50,
- 分析合理最大并发数，使用合理最大并发数，进行长时压测验证结论
- 注意事项：
- 如果高并发出错率偏高，可以尝试降低并发数，以获取更合理的结果
- 实际工作过程中，发压机与被压测应用需要运行在不同机器上
压测实施
- 通过对比并发数与流量还有错误率的关系，找到一个最合理的系统可支撑最大并发数
- 可以先把并发数往大增加，压出问题之后，再逐步减少
- 找到系统可以支持的最合理最大并发数
- Demo-逐步增加并发数的压测过程，压测报告解读，记录数据分析结果
压测结果
image.png
image.png
- 分析结果，最优并发数在10-20之间，然后再细化脚本中的并发数为（10 12 14 16 18）
小结
- 运行自动压测，实施压测运行
- 并发数设定原则：从小->大，先粗粒度，再细化
- 应用系统的流量与并发数的对应关系
- 错误率与并发数的关系
- 系统合理能力的判断与验证
- 性能监控压测运行状态
