写在前面
本地跑jmeter，电脑环境、网络环境等都会影响压测结果产生误差，压测的目的当然是希望能无限接近真实情况，一般参考服务器压测。
-
线上压测需谨慎（整出问题了领导可能要喊你去喝茶~），需要评估影响范围，防止对其它系统造成影响，建议步骤：
1、被压系统只能抽掉一台服务器进行压测，先摘掉流量，被压机器不能同步提供线上服务，其他服务器要能正常提供服务；
2、确定压测计划，包含压测时间、压测方法、放量节奏（只允许逐步放量，最高不能超过10倍）、监控方法、监控人；
3、最好是邮件或群里周知一下，包括你的下游；
一、权限申请
- 服务器压测需要申请服务器环境
- 1.master机器权限：用于搭jmeter环境、执行压测脚本，所以需要sudo权限；
- 2.目标机器权限：用于压测过程查看log，普通权限即可；
二、环境搭建
1.ssh ip登上申请的master服务器，查看linux内核是32位还是64位（需要下载对应的jdk）命令 cat /proc/version
2.下载jmeter--官网
3.下载linux版本jdk--官网
4.cd到master机你的目录下，创建一个temp文件夹，用于存放jdk和jmeter安装包
5.cd到temp下，sudo rz -be回车，把jmeter和jdk传到linux上
6.解压jdk和jmeter
sudo tar -zxvf jdk-17_linux-x64_bin.tar.gz
sudo tar -zxvf apache-jmeter-5.4.3.tgz
7、配置jdk和jmeter环境变量
sudo vim /etc/profile，输入i进入编辑模式，脚本内容为：
#jdk
export JAVA_HOME=/home/chunzhij/temp/jdk-17.0.1
export JRE_HOME=${JAVA_HOME}/jre
export CLASSPATH=${JAVA_HOME}/lib:${JRE_HOME}/lib
export PATH=${JAVA_HOME}/bin:$PATH
#jmeter
export JMETER=/home/chunzhij/temp/apache-jmeter-5.4.3
export PATH=${JMETER}/bin/:${PATH}
copy进去后esc退出编辑模式，:wq保存编辑，执行source /etc/profile环境变量配置才能生效。
到这里环境应该是搭好了。
8.sudo jmeter --v运行jmeter看看是否装成功 ，图片这样就是成功了
三、压测示例
以一个简单的http接口为例，本地jmeter写好压测脚本传上去就可以跑了
操练一下吧~
1.cd到之前创建的temp目录下，上传写好的压测脚本sudo rz -be
2、执行压测sudo jmeter -n -t HTTP请求.jmx，执行过程中能实时看到压测结果，如果想停止ctrl+c就行
3.压测过程中，同时要关注目标机器能耗情况和日志，多开几个linux窗口，登上目标服务器，当然如果你们公司有监控平台，机器监控可以上监控平台看
- 查看压测机器cpu使用情况
top -bn 1 -i -c - 看下目标机器日志有没有报错，这个一般就进到你的日志存放目录，
tail -f 文件名 |grep error
4、生成压测报告test.jtlsudo jmeter -n -t HTTP请求.jmx -l test.jtl，在temp目录下ls能看到生成的test.jtl文件
5、下载测试报告到本地 sz /xxx/temp/test.jtl，xxx是你的路径，方便后续压测结果的分析，这个文件可以导入到jmeter里
6、如果需要多次测试不同参数，需要先删除linux的所有上次测试 jtl与jmx文件后，并且在本地按照上述重新设置好新参数，上传服务器进行执行。
四、压测结果分析
1、业务指标
- 业务核心监控
- 业务主要请求接口；
- 接口请求响应时间是否合理（需关注平均响应时间、P90、P95、P99响应时间）
- 业务接口失败数，
- 下游系统的接口请求量，失败数，中间件相关监控
示例：
summary = 287323 in 00:00:39 = 7442.4/s Avg: 3 Min: 2 Max: 57 Err: 0 (0.00%)
summary + 237005 in 00:00:30 = 7900.2/s Avg: 3 Min: 2 Max: 45 Err: 0 (0.00%) Active: 24 Started: 24 Finished: 0
说明
summary + :是增量的值；
summary = :是当前的累计值；
summary =287323 in 00:00:39：在39秒内产生的总请求数是287323 个，其中的时间段是从脚本运行开始计算到当前时间为止，一般在脚本运行过程中主要关注 “summary=” 信息即可；
7442.4/s：系统每秒处理的请求数，相当于TPS；
in 00:00:39 = 7442.4/s:总执行时长，平均执行速度=7442.4/00:00:39；
Avg: 3：平均响应时间；
Min: 2：最小响应时间；
Max: 57：最大响应时间；
Err: 0 (0.00%)：错误数/率；
Active: 24：活动的线程数；
Started: 24启动的线程数；
Finished: 0完成的线程数；
说明
Samples：本次测试场景共运行多少线程；
average：平均响应时间；
median：统计意义上的响应时间中值；
90%line：所有线程中90%的线程响应时间都小于xx的值;
95%line：所有线程中95%的线程响应时间都小于xx的值;
99%line：所有线程中99%的线程响应时间都小于xx的值;
min：最小响应时间；
max：最大响应时间；
error：错误率；
throughput：吞吐量——默认情况下表示每秒完成的请求数（Request per Second) 可类比为qps
received：接收数据量
sent：发生数据量
2、机器指标
- 负载（load）：cpu核数*0.6以下
- CPU：60%~80%之间
- FGC：频次和时间不会增长
- 内存
- 磁盘读写
- 网络流量
这些指标一般公司都有机器监控平台，可以很直观的看到压测期间的波动情况，便于结果分析。
