Jmeter电商系统压测实战＜二＞

一、Jmeter优化tips

1. 使用命令行操作
2. 尽量避免使用监听器/断言等
3. 增加JVM的堆空间（压力越来越大时，需要的堆空间越大，这个值不要太小也不要太大，适中最好）
4. 尽可能使用最新的Jmeter版本（这样性能会更好，也可以获取最新的功能点）
5. 尽可能使用正则表达式的方式提取响应数据（但是这样也会消耗cpu性能，待商榷）
6. 每台机器配置合理数量的线程数 （建议小于1000个线程数）
7. 分布式压测：将负载平均分配到每台机器。与其用一台16核128g的机器，不如用4台4核16g的机器替代，因为jvm无法在超过16g的内存里工作的很好
8. 执行完压测后再生成报告（因为这个比较耗cpu和内存）
9. 在大多数情况下网络是个瓶颈
10. 避免使用beanshell脚本 ：因为要用更多的cpu，推荐用JSR223采样器中嵌入的groovy脚本，或者JSR223的post或者pre中完成
11. 不要在分布式模式下执行压测：分布式模式单台的master，slave承载的限度是有限的，推荐分布式最好在20-30台的slave之间，只能在网络环境非常好才能达到40-50台的并发，单台限制2w-5w左右的并发，单台能承载1000左右的并发
12. 监控测试发压机和压力机：推荐使用Prometheus监控手段完成监控
13. 先在内网进行压力测试：发压机和压力机尽量在一个网络，比如在内网，因为内网网络传递速度比较快，尤其是有好的路由或交换器的时候

二、Jmeter的使用建议-参数配置

1. XX:MaxMataspaceSize（jdk8的参数）

这个参数用于限制Mataspace（堆外内存：Metaspace 区域位于堆外，所以它的最大内存大小取决于系统内存，而不是堆大小，我们可以指定 MaxMetaspaceSize 参数来限定它的最大内存）增长的上限，防止因为某些情况导致Mataspace无限的使用本地内存，如果超过设置的值就会触发Full GC，此值默认没有限制，应取决于系统内存的大小，jvm会动态的改变此值。例如：

// 如果是一台4g的机器，直接设置成4096m即可
-XX:MaxMataspaceSize=4096M

2. -Xmx2048m

设置堆内存最大值为512m，这个值推荐设置成2048m

3. -Xms1g

设置堆内存的最小值为1g（ps：-Xms和-Xmx实际上是 -Xx:InitialHeapSize和 -XX: MaxHeapSize的缩写。例如：-XX: InitialHeapSize=123m -XX: MaxHeapSize=2g）

三、Jmeter插件

1. 介绍及安装

• Plugins Manager：https://jmeter-plugins.org/install/Install/
• 优势：这里安装插件可以自动添加所需依赖
• 使用方式：
  下载管理插件，plugins-manager.jar，将plugins-manager.jar拷贝到Jmeter的lib/ext目录下，重新打开Jmeter在options菜单可以看到如下界面
  
  

2. 常用插件

• Auto-Stop Listener ：错误率达到设置的值就自动停止
• HTTP/2 Sampler：http2协议用的采样器
• PerfMon：同时监控发压机和被测机性能（不太建议使用）
• Random CSV Data Set：之前的csv data set config都是从头读到尾，如果是多台slave，所以slave同一时间可能都会去读第一个，会导致缓存出现问题。用这个可以随机读取，就不用给磁表文件分片
• Redis Data Set：从redis获取压测磁表
• Custom Thread Groups：定制的thread group，它有2种模式，第一种是Utimate Thread Group，就是并发线程组的方式。第二种是Free-Form Arrivals Thread Group：自带的Thread Group是按照自定义的线程数去控制并发，得到qps。这个是按QPS去控制并发，不用指定并发用户数，如果需要限制qps可以用这个去做

例子：

前面都是按照线程数，这里按照qps的概念来做了

四、Jmeter日志收集

1. 概览

压测过程中如果我们想要看报错，就需要看日志。因为压测执行人可能会有多个，可能所有人都在看这个错误，但是不能每个人都在一台机器看，这个时候就需要用到分布式日志收集方式，本次我们用的是ElasticSearch+FileBeats+Kibana的架构

• ES：日志存储
• FileBeats：日志收集
• Kibana：日志展示
  
  收集前我们需要安装并编辑对应的配置文件：

2. elk，kibana和es的安装和配置

// 下载并解压到本地，然后编辑配置文件
wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-oss-7.5.1-darwin-x86_64.tar.gz --no-check-certificate
tar -xzf filebeat-oss-7.5.1-darwin-x86_64.tar.gz
Vi filebeat.yaml

编辑配置文件时，我们重点关注这些：

• 是否开启input config
• 日志需要从哪里获取
• 有哪些行是想要的/不太想要的（3个都在截图里）
  

日志输出路径：因为这个给的是elk，这里会修改成对应的端口号

下载elk

// 启动kibana （这里限制jvm参数，因为该机器性能一般）
docker run -e ES_JAVA_OPTS="-Xms256m =Mmx256m" -idt -p 9202:9200 -p 5602:5601 nshou/elasticsearch-kibana

浏览器验证es是否启动了

验证kibana是否启动了

配置filebeats：这些是常见的要修改的地方

vi filebeat.yml

纠正下，第二个是配置分隔符，按照什么进行分行

jmeter会生成2类日志，一个是jmeter.log，另一个是error.log，如果我们只想要打印错误日志，目前有2种方式

jmeter常用的存储变量的工具
1，ctx：
2，vars：存在jmeter变量后，可以通过vars去get/set
3，props：可以在运行时去改动jmeter原生的属性，比如说去修改开始结束时间的格式
4，prev：可以通过这个拿到上一个请求的result结果，并基于这个去做下一步的动作

• 第一种：查看结果树里（不推荐，会消耗性能）
  
  这个时候在kibana就可以收到
  这里记得加一个pattern
  
  如果不确定index是啥，可以通过dev tools进行确认
  
  我们如何对日志进行过滤，只展示error级别的呢
  我们可以选择添加这个
  
  当然我们更倾向添加JSR223 listener
  

这里写了一段脚本，意思是如果code!=200,则打印出error

我们可以在kibana查看到对应日志
这样我们就基本能拿到客户端的比较全的监控了

3. Prometheus和Node Exporter，grafana的安装及配置

戳这里

• Prometheus架构：

  • 分为三层，第一层是数据发送方node exporter；第二层是数据存储方prometheus server；第三层是数据展示方：如grafana或者prometheus web ui。
  • 具体：prometheus的target：通过各种各样的jobs或者exporters，把指标打到prometheus上，prometheus把它存到数据库，并且通过sql的查询方式通过如grafana来访问调用存储的数据，并且prometheus配合alert manager采集数据，通过email，企业微信等方式发送报警。

  配置完成以后我们查看报表，可以看到jmeter达到瓶颈的同时，机器性能总体是比较优，并没有什么异常表现，还在可接受范围，这个时候我们可以从其他角度拿到服务端压测数据，并对其进行分析
  

五、Spring JVM，Mysql，Redis，MongoDB调优

如果被测应用是springboot应用，想对其jvm或者springboot进行监控可以用micrometer插件

操作步骤：

1. 添加依赖

<dependence>
  <groupId>io.micrometer</groupId>
  <artifactId>micrometer-registry-prometheus</artifactId>
  <version>1.3.5</version>
</dependence>

2. 配置文件
   在这个yml文件进行配置
   

3. push image到远程仓库
   配置完记得点击右边的package进行打包，这边配置了docker插件，会自动push到远程
   

4. docker Image暴露对外接口：

docker run -p9100:9100 -p 8001:8001 -p 8085:8085 --name mall-portal --link mall-mysql:db --link mall-redis:redis --link mongo:mongo --link rabbitmq:rabbit -v /etc/localtime:/etc/localtime -v /mydata/app/portal/logs:/var/logs -d mall/mall-portal:1.0-SNAPSHOT

配置完之后访问这个，如果可以正常访问就表示配置成功了

为啥要在这个目录去找呢？因为我们在配置文件就是这么配置的
base-path

8001

5. 编辑prometheus.yml文件
   编辑这个文件，加上这部分，然后保存
   

• 查看Prometheus里是否能够拿到9090端口
  如果在这里能看到spring，看到状态和值，
  
  介绍一下里面的指标值

• jvm_classes_loaded_classes
  
• jvm_threads_peak_threads
  
• jvm_gc_xxx

• system_cpu_xxx

• 当yml配置文件的auto-time-requests:true时，会把接收到的请求，请求的状态，响应耗时打印出来
  
  总结一下，我们可以通过这个micrometer获取jvm所有信息和tomcat的session信息和服务请求的详情信息，还有当前进程和系统的cpu情况。

因为这样显示不太直观，我们直接来用报表展示

6. 添加报表
   首先我们需要搜索插件：
   
   添加插件：
   

查看报表：
我们可以看到启动时间，首次启动时间，堆内存使用占比，非堆内存的使用占比等参数

• rate：请求的qps占比
• errors：错误数
• duration：不等于5xx的响应请求数
• utilsation：tomcat的使用情况
  
• jvm heap：jvm堆内存具体使用情况
• jvm non-heap：jvm非堆内存使用情况

jvm的cpu，活跃线程数等属性

gc的一些属性，比如耗时啥的