1. 相关文档
- 10分钟讲完Jmeter接口测试（快速上手教程） （简单的快速入门视频）
- 压力测试-JMeter安装、入门、结果分析 （快速入门+参数介绍）
- 手把手教你压测 （快速入门+Jmeter插件安装+Linux服务器监控）
- jmeter如何查看TPS、RT指标 （查看被压测的服务器指标）
- jmeter提取json数据进行接口参数关联 （scene1：上个接口的返参作为下个接口的入参）
- jmeter如何采用json提取器提取多个值 （scene1_plus：从上个接口的返参中提取多个值作为下个接口的入参）
- Jmeter插件Active Threads Over Time监听单位时间内活动的线程 （线程组参数详讲）
- jmeter逻辑控制器-吞吐量控制器的使用 （scene2：单接口下用户访问商品AB的比例控制 or 读写接口混合压测模式下，28原则比例分配）
- jmeter逻辑控制器-交替控制器的使用 （scene3：用户访问商品列表页，第一个用户下单商品A，第二个用户下单商品B，依次下单）
- jmeter逻辑控制器-事务控制器的使用 （事务是完成一个业务所调用接口的集合，当然也可以是单个接口）
- JMeter基础系列(八) JMeter断言之JSON断言 （JSON断言详讲）
- 登录参数化CSV 数据文件设置（五） （读取CSV文件中的用户账号,密码,cookie等）
2. Jmeter UI功能介绍
1）创建线程组
2）创建HTTP请求
加个请求头
3）添加监听器-查看结果树
4）安装Jemeter插件：3 Basic Graphs、5 Additional Graphs 和 PerfMon（服务器性能监控插件）
5）运行服务端的监控程序：PerfMon Server Agent
6）Run起来
7）scene1：上个接口的返参作为下个接口入参
8）scene2：单接口下用户访问商品AB的比例控制 or 读写接口混合压测模式下，28原则比例分配
9）对HTTP响应结果进行JSON断言
10）读取CSV文件中的用户账号,密码,cookie等（每个线程执行一次都会取一个新的UID！）
3. 常见压测问题
线程池
- 核心线程和最大线程数设置太小，导致任务大量排队等待，RT升高； （IO密集型保守设置：corePoolSize=CPU核数*2）
- 通过实际压测结果调整线程池配置；dubbo默认核心线程数=最大线程数=200、队列长度0、拒绝策略；
代码逻辑复杂度
- for循环中嵌套bigList.contains(value)方法，复杂度过高，导致CPU飙升；
- for循环操作DB，和DB交互次数变多，导致RT升高；
数据库DB
- 查询时没有命中索引，或无索引，导致RT较高；
- 并发更新单条纪录，导致大量锁等待，RT增加；（MySQL热点key更新最大支持qps1k，实际业务500左右）
缓存Cache
- Redis和Caffeine中查询缓存为null时，没有放empty值导致缓存穿透，RT增加；
RPC
- 下游服务性能较差，导致耗时太多；
- 下游服务dubbo线程池满了，导致大量异常；
JVM
- OOM（内存泄漏、导出数据时未加锁、异步打印大对象日志）
- CPU飙高（代码复杂度过高、频繁GC、锁竞争等）
4.JVM调优实战场景
1）CPU飙高：代码复杂度过高
测试demo：
jmeter进行压测此接口：
按此步骤进行排查cpu飙高原因排查：
top // 查看各个进程cpu使用情况
top -Hp 11391 // 查看该java进程下所有线程cpu使用情况
printf %x 11405 // 线程ID转换16进制
jstack 11391(进程ID) | grep 2c80(十六进制线程Id) // 查看堆栈信息
jstack 11391 > out.txt // 输出thread dump文件
fastthread.io // 在线分析dump文件
fastthread.io 在线分析dump文件，如下：
Refer：jstack命令解析（分析死锁、CPU过高）、包教包会 jstack分析性能问题
2）OOM：一次性申请对象太多
项目配置jvm参数：
测试demo：
异常日志：
dump文件分析：找内存占用过大的对象 -> 这个对象被谁引用（GC Root）-> 具体所在的代码
OOM问题有两类最常见的GC Root:
1. 静态变量类，特征为GC Root可追踪到某个静态变量。这类问题有较大概率是缓慢泄漏，
在发生OOM的时刻没有对大对象进行写入操作的话，无法从线程上找到对应代码。
2. 方法局部变量类，特征为GC Root可追踪到某个线程。
这类问题发生OOM的时刻大概率可追踪到问题根因的线程。
以下分析使用的是VisualVM工具：
总结，OOM问题定位思路：
配置Jvm参数：PrintGCDetails（打印gc日志）、 HeapDumpOnOutOfMemoryError（生成dump文件）
获取dump文件；
使用内存分析工具对dump文件进行分析：Visualvm、Mat、Arthas等工具；
// dump文件分析：找内存占用过大的对象->这个对象被谁引用（GC Root）-> 具体所在的代码
修改验证。
