性能测试
jmeter创建多少用户——》java可以创建多少个线程数
- java堆 heap -xms -xmx2048m即2g
- 物理内存32g
在bin文件内找到bat文件，右键通过notepad++编辑打开，ctrl+f搜索heap，找到如下图就能判断jmeter被设置heap有多大：
这里表示有5g
性能压测：
场景业务：订单模块
场景类型：负载测试
压测环境：
- 服务器环境：
- 测试机环境：8c32G win10 jmeter5.3
场景设置：
- 启动时间：2s
- 持续运行时间：200s
场景指标：
- tps: 5000
- 响应时间：<1秒
- 服务器资源：cpu<80%，内存<80%
- 错误率：<0.05%，即1万个里只能有五个错误
压测数据：
性能分析流程：
1、jmeter聚合报告的指标异常
- rt响应时间30s>1s不符合预期
- 错误率==符合预期
- 秒杀Tps<1万不符合预期
2、分析服务器资源情况——grafana监控分析
- cpu ———cpu爆满
- 内存
- 磁盘
- 网络
- 进程
3、哪一个具体的分支导致cpu利用率爆满——grafana监控分析
- user 用户进程———接近100%导致了cpu爆满
- system 系统进程
- iowait 磁盘io
- si 终端
- idle ？
4、那具体哪一个用户进程消耗cpu资源
压测时同时使用 linux top命令看具体的进程资源 得到如下图：
7-性能分析与调优_哔哩哔哩_bilibili17:20会说明怎么看top出来的东西
上图表明mysqld使用cpu资源最大，tps靠的java只占了400cpu里的30，所以tps低
5、分析组件——mysql
- 组件的专项分析
6、了解mysql的性能指标
- 执行效率
- buff
- 锁问题
- 表结构
- 库结构
- 部署集群
7、使用工具分析——grafana监控分析
- 有大量慢查询
8、看你的具体情况
- 有测试环境的mysql权限可以直接继续分析
- 没有数据库权限，可以告知对应的人员
9、分析具体哪一条语句导致的慢查询
- ctrla+ctrlc复制出来，重新单独运行找到的这条语句，发现得耗时0.657s，之前的8秒是因为并发压测
- 看下语句的解释，是什么原因
如这里是这两处的原因
10、找到对应的慢查询语句——跟开发沟通确认是否是这个场景的语句
11、开会/评审，确认bug
12、开发优化——回归测试 ，开发优化了表，运行开发优化表的语句后，先单独运行之前的这条查询语句看看，此时这条语句只耗时0.006s
13、继续重新回归压测场景——分析
14、现在的回归压测的指标情况
- 响应时间<1s
- tps数量上升
- 但服务器资源cpu%还是很高——继续分析
结论：
建议方案：
监控方案：
- severagent.jar-----jmeter自带的？
- nmon+分析器
- grafana
- zabbix
- 宝塔BT
- skywalking
- 云监控
- top
