摘要：
如何找出性能测试中是否存在性能瓶颈？你必须从结果表中找到鸭子！
如果你想从头学习Jmeter，可以看看这个系列的文章哦
https://www.cnblogs.com/poloyy/category/1746599.html
前言
可以搭配上一篇博客来看哦，是一个整体内容：https://www.cnblogs.com/poloyy/p/13278920.html
Charts 介绍
- 包含了各种详细信息图表，比 GUI 模式的图表好看且易懂多了！
- 做性能测试，如何发现是否有性能瓶颈？必须从结果图表中找到鸭！
- 而 html 报告将性能测试可能需要用到的图表都加进去了，可谓是6666
一共有三大模块
- Over Time
- Throughput
- Response Times
Over Time
一共有 6 个图表
- Response times Over Time
- Response times Percentiles Over Time
- Active Threads Over Time
- Bytes throughput Over Time
- Latencies Over Time
- Connect Time Over Time
=======>>>> 点击右侧即可跳转对应图表哦
Response times Over Time
- 脚本运行期间，不同事务（请求）的响应时间变化趋势图
- 包括事务控制器样本结果
- 重点：可以根据响应时间和变化和TPS以及模拟的并发数变化，判断性能拐点的范围
- 一条线代表一个事务（请求）
Response times Percentiles Over Time
- 脚本运行期间，成功的请求的响应时间百分比分布图
- 可理解为聚合报告对应的指标（图二）
Active Threads Over Time
- 脚本运行期间，每个线程组的活跃线程数变化趋势图
- 一个线程组对应一条线
Bytes throughput Over Time
- 脚本运行期间，吞吐率变化趋势图
- 在容量规划、可用性测试和大文件上传下载场景中，吞吐量是很重要的一个监控和分析指标
- 会忽略事务控制器样本结果
Latencies Over Time
- 脚本运行期间，发送一个完整的请求所需时间的变化趋势图
- 可理解理解成：从发送请求到收到第一个响应所花费的时间
- 包括事务控制器样本结果
Connect Time Over Time
- 脚本运行期间，事务（请求）建立连接所花费的平均时间变化趋势图
- 包括 SSL 三次握手的时间
- 当出现链 Connection Time Out 的错误时，Connect Time 就会等于链接超时时间
对应 Jmeter 监视器的元件
Throughput
- Hits Per Second
- Codes Per Second
- Transactions Per Second
- Total Transactions Per Second
- Response Time Vs Request
- Latency Vs Request
=======>>>> 点击右侧即可跳转对应图表哦
Hits Per Second
每秒点击数
Codes Per Second
脚本运行期间，响应状态码的数量变化趋势图
Transactions Per Second（最重要）
- 每秒事务数，即 TPS
- 衡量系统处理能力的重要指标
- 包括事务控制器样本结果
Response Time Vs Request
平均响应时间与每秒请求数的关系图
Latency Vs Request
完成一个完整的请求所需平均时间与每秒请求数的关系图
对应 Jmeter 监视器的元件
Response Times
- Response Time Percentiles
- Response Time Overview
- Time Vs Threads
- Response Time Distribution
=======>>>> 点击右侧即可跳转对应图表哦
Response Time Percentiles
- 响应时间百分比分布图
- 响应时间在某个百分比范围内的请求在所有请求数中所占的比率，相比于平均响应时间，这个值更适合用来衡量系统的稳定性。
Response Time Overview
- 响应时间分布图
- 展示落在各个平均响应时间区间的请求数情况
Time Vs Threads
- 平均响应时间和线程数的对应变化曲线
- 可以通过这个对应的变化曲线来作为确定性能拐点的一个参考值
- 可以选中或取消选中下面的 Sampler
Response Time Distribution
- 响应时间分布图
- 不同响应时间区间内，成功响应数是多少
