最后更新：2026-09-04 01:19

实验22 性能测试结果分析¶

难度：★★☆　|　预估时长：__ 分钟

22.1 实验目的¶

知识目标：理解 JMeter 聚合报告各列含义（Median、90%/95%/99% Line、Error%）与 LoadRunner 各类分析图的作用；理解 CPU、内存、磁盘、进程、网络的瓶颈判定指标与阈值。
技能目标：能使用 JMeter（Summary Report / 聚合报告 / Dashboard）与 LoadRunner Analysis（Vusers 图、错误图、事务图、Web 资源图、网页诊断图）分析测试结果，并按阈值判断系统资源瓶颈。
素养目标：养成"先看事务成功/失败，再看响应时间与曲线走向，最后查资源"的有序分析习惯，能基于数据得出性能结论而非凭感觉下判断。

22.2 实验环境¶

操作系统：Windows 10 / Windows 11；
工具：JMeter（+ 插件）+ LoadRunner（Analysis）；
被测系统：人力资源综合服务系统（http://192.168.X.XXX/suthr/logon）；
前置：实验19 / 实验21 的运行结果数据。

22.3 实验重难点¶

重点：聚合报告各列含义（Median、90%/95%/99% Line、Error%）；事务图关键图（TPS、平均响应时间）的分析；内存/CPU/磁盘瓶颈判定指标与阈值。

难点：TPS 曲线走向分析（平坦趋势=瓶颈征兆）；内存分析方法（Page Reads/sec 阈值 5）；磁盘 I/O 计算（RAID 公式）；响应时间与负载、事务数的联动分析。

22.4 实验内容¶

22.4.1 基于 JMeter 的结果分析¶

1. 任务描述 掌握 JMeter 的 Summary Report 与聚合报告分析。

2. 实验步骤

步骤 1：Summary Report（右击测试计划/线程组 → 添加 → 监听器 → Summary Report）：表格显示取样器结果。注意：不同取样器不要取相同名字，否则会统计到同一行。
步骤 2：聚合报告（Aggregate Report）——JMeter 最常用监听器，关键列： | 字段 | 含义 | | --- | --- | | #Samples | 请求总数（10 用户 × 迭代 10 次 = 100） | | Average | 平均响应时间（毫秒） | | Median | 中位数：50% 请求不超过该时间 | | 90% / 95% / 99% Line | 90% / 95% / 99% 请求不超过该时间 | | Error % | 出错率 = 错误请求数 / 请求总数 | | Throughput | 吞吐量（TPS） |
步骤 3：开源监听器（装 jpgc-Standard Set / PerfMon 插件）：
- Transactions per Second：每秒事务数（TPS）曲线；
- Response Times Over Time：响应时间过程图；
- PerfMon Metrics Collector：监控服务器 CPU/内存/磁盘/网络（被监控机需装并启动 ServerAgent，默认端口 4444）。
步骤 4：Dashboard 报告（非 GUI 运行生成，浏览器打开 index.html）：APDEX 指数、Requests Summary（成功/失败占比）、Statistics（指标摘要）、Errors / Top 5 Errors、Charts（Over Time / Throughput / Response Times）。

为什么要看 90% Line，而不是只看平均值？

平均值像"全班平均分"——会被少数特别慢的请求拉高或掩盖。90% Line 告诉你"90% 的请求都不超过这个时间"，更接近大多数用户的真实感受。

常见错误与排错

若两个取样器的结果统计到同一行：不同取样器不要取相同名字；
若 PerfMon 监控无数据：确认被监控机已安装并启动 ServerAgent（默认端口 4444）。

22.4.2 基于 LoadRunner Analysis 的结果分析（一）Vusers 图与错误图¶

1. 任务描述 掌握 Vusers 图与错误图的作用。

2. 实验步骤

步骤 1：Analysis 是 LoadRunner 收集和分析负载测试数据的工具，提供图和报告。
步骤 2：Vusers 图（Vuser 整体运行情况，与事务图结合可看 Vuser 数对响应时间的影响）：
- Running Vusers：每秒执行脚本的 Vuser 数及状态；
- Vuser Summary：Vuser 性能摘要；
- Rendezvous：集合点释放 Vuser 的时间与数量。
步骤 3：Errors 图（查看因错误失败/停止/终止的事务）：
- Error Statistics（by Description）：按错误描述分组；
- Errors per Second（by Description）：按错误描述的每秒平均错误数；
- Total Errors per Second：每秒平均错误总数。

为什么 Vusers 图要和事务图结合看？

单看 Vusers 图只知道"多少人在线"，单看事务图只知道"处理得快不快"——两者叠在一起，才能看出"用户数一增加，响应时间跟着怎么变"，这正是负载分析的核心。

22.4.3 基于 LoadRunner Analysis 的结果分析（二）事务图¶

1. 任务描述 掌握事务图的种类与分析要点。

2. 实验步骤

步骤 1：Transaction Summary（事务概要）：失败/通过/停止/错误结束的事务数摘要。性能分析的第一步——通过事务成功与失败情况直接判断系统是否运行正常：通过事务越多=处理能力越强，失败越少=越可靠。
步骤 2：Average Transaction Response Time（事务平均响应时间）：每秒执行事务的平均时间，可对比可接受范围判断性能是否达标。
步骤 3：Transactions Per Second（TPS）：每秒各事务通过/失败/停止次数，考查系统性能的重要参数。分析 TPS 主要看曲线走向：
- 随负载增加 TPS 逐渐增加；
- 系统进入繁忙期后 TPS 会下降；
- 压力加大时 TPS 曲线变化缓慢或平坦 → 很可能服务器开始出现瓶颈；
- 与平均响应时间对比，分析事务数对执行时间的影响。
步骤 4：Total Transactions Per Second：每秒通过/失败/停止的事务总数。
步骤 5：Transaction Performance Summary（事务性能概要）：所有事务的最小/最大/平均性能时间，判断响应时间是否符合要求。
步骤 6：Transaction Response Time Under Load（事务响应时间-负载下）：Running Vusers 图 × 平均响应时间图组合。线条越平稳说明系统越稳定，分析逐渐加压场景最有用。
步骤 7：Transaction Response Time (Percentile)：给定时间内执行的事务百分比——最大响应时间可能特别长，但若大多数事务响应时间可接受，则整体符合需求。
步骤 8：Transaction Response Time (Distribution)：事务执行时间分布。

TPS 曲线变平坦说明什么？

压力还在加大、TPS 却不再上涨，就像再多的收银台排队人数也挤不出更多结账量——很可能服务器开始出现瓶颈，这是 TPS 分析最关键的信号。

22.4.4 基于 LoadRunner Analysis 的结果分析（三）Web 资源图与网页诊断图¶

1. 任务描述 掌握 Web 资源图与网页诊断图的分析。

2. 实验步骤

步骤 1：Hits per Second（每秒点击次数）：每秒 Vuser 向 Web 服务器发的 HTTP 请求数。点击率下降通常表明服务器响应变慢，需进一步分析找瓶颈。
步骤 2：Throughput（吞吐量）：每秒从服务器获得的总数据量（字节）。与点击率的区别：点击率=每秒 HTTP 申请数，吞吐量=每秒获得的数据量。
步骤 3：HTTP Status Code Summary / HTTP Responses per Second：按状态代码分组的返回数，可定位生成错误代码的脚本。

步骤 4：Pages Downloaded Per Second：每秒下载的网页数（需在 Run-time Settings→Preferences 勾选 Pages per second）。
步骤 5：Retries per Second / Retries Summary：每秒服务器重试连接次数 / 按重试原因分组（初始连接未授权、要求代理验证、服务器关闭连接等）。
步骤 6：Connections / Connections Per Second：打开的 TCP/IP 连接数 / 每秒新连接数。连接数达最大值时响应时间会急剧增加。理想情况是许多 HTTP 请求复用同一连接（新连接成本很高）。
步骤 7：网页诊断图（评估页面内容是否影响事务响应时间）：
- Web Page Diagnostics：每个网页及其组件的下载时间；
- Page Component Breakdown：各组件平均下载时间（找最慢组件可双击"平均值"列排序）；
- Page Download Time Breakdown：按 DNS 解析、连接、第一次缓冲、SSL 握手、接收、客户端等细分下载过程；
- Time to First Buffer Breakdown：区分网络时间与服务器时间；
- Downloaded Component Size：组件大小（大的组件需优化）。

点击率和吞吐量有什么区别？

点击率是"每秒寄了多少件快递"（HTTP 请求数），吞吐量是"每秒收到多少斤货物"（数据量）——件数多不代表重量大，两者要分开看。

22.4.5 系统资源分析方法¶

1. 任务描述 掌握 CPU、内存、磁盘、进程、网络的资源瓶颈分析方法。

2. 实验步骤

步骤 1：内存分析方法：
1. 查看 Memory: Available Mbytes（可用物理内存）；
2. 查看 Pages/sec、Page Reads/sec、Page Faults/sec（系统与磁盘交互频率）。Page Reads/sec 阈值是 5，超过 5 可判定内存问题；
3. 若 Page Reads/sec 很低，同时 %Disk Time 和 Avg. Disk Queue Length 很高 → 磁盘瓶颈；若队列长度增加但 Page Reads/sec 未降 → 内存不足。
4. 内存瓶颈征兆：很高换页率、进程进入不活动状态、交换区磁盘活动高、全局系统 CPU 利用率高、内存不够错误。
步骤 2：处理器分析方法：
1. Total %Processor Time：全部 CPU 平均利用率，超过 90% 说明处理器瓶颈（多 CPU 负载不均衡也视作瓶颈）；
2. %User Time 大 → 可考虑算法优化；%Privileged Time 高；
3. System: Processor Queue Length > CPU 数 + 1 → 处理器阻塞；%DPC Time > 50% 且 %Processor Time 很高 → 网络不饱和，可加网卡。
4. CPU 瓶颈征兆：很慢响应时间、CPU 空闲时间为零、过高的用户/系统占用 CPU、长时间很长的运行进程队列。
步骤 3：磁盘瓶颈分析方法：
1. 计算每个磁盘 I/O 并与磁盘标称 I/O 能力对比。RAID 公式：
  - RAID 0：(Reads + Writes) / 磁盘数；
  - RAID 1：(Reads + 2×Writes) / 2；
  - RAID 5：(Reads + 4×Writes) / 磁盘数；
  - RAID 10：(Reads + 2×Writes) / 磁盘数。
2. 与 %Privileged Time 合并分析：只有 %Disk Time 大 → 硬盘可能是瓶颈；数值都大且持续超 80% → 可能内存泄漏；
3. Avg. Disk sec/Transfer：<15ms 最佳，15~30ms 良好，30~60ms 可接受，>60ms 为磁盘瓶颈。
4. I/O 瓶颈征兆：过高磁盘利用率、太长磁盘等待队列、等待磁盘 I/O 时间百分率太高、过长运行进程队列但 CPU 空闲。
步骤 4：进程分析方法：
1. %Processor Time：对比各进程消耗，找消耗最多的进程；
2. Process: Page Faults/sec 与 Memory: Page Faults/sec 的比值，判断哪个进程产生最多页面失效；
3. Process: Private Bytes：判断内存泄漏——性能测试中该值持续增加，或测试停止后仍处高水平 → 存在内存泄漏（如 IIS 应用监控 inetinfo 进程）。
步骤 5：网络分析方法：Network Interface: Bytes Total/sec 与网络带宽比较，判断网络连接速度是否是瓶颈。

内存不足和磁盘瓶颈怎么区分？

看组合症状：Page Reads/sec 很低、但 %Disk Time 和磁盘队列很高 → 偏向磁盘瓶颈；磁盘队列在涨、Page Reads/sec 却不降 → 说明系统在疯狂换页，是内存不足。单看一个指标容易误诊。

常见错误与排错

内存问题判定：Page Reads/sec 超过阈值 5 才可判定，别看到一个换页数字就下结论；
处理器问题判定：Total %Processor Time 超过 90% 说明处理器瓶颈；%DPC Time > 50% 且 CPU 很高时，可考虑加网卡；
磁盘问题判定：Avg. Disk sec/Transfer 超过 60ms 才是磁盘瓶颈（15ms 内最佳）。

22.4.6 实例：综合结果分析¶

1. 任务描述 运行"添加岗位"测试，综合 JMeter 与 LoadRunner 结果得出性能结论。

2. 实验步骤

步骤 1：JMeter 端：添加 Summary Report、聚合报告，查看 TPS、响应时间、Error%。
步骤 2：LoadRunner 端：Analysis 中查看 Transaction Summary、Average Transaction Response Time、TPS、Hits per Second 等图。
步骤 3：监控服务器资源（CPU、内存、磁盘），结合阈值判断是否存在瓶颈。
步骤 4：按"事务成功/失败 → 响应时间是否达标 → TPS 曲线走向 → 资源是否饱和"的顺序给出性能结论。

22.5 实验总结¶

本次实验掌握了以下要点：

一是理解了聚合报告各列（Median、90%/95%/99% Line、Error%）与 LoadRunner 各类分析图的作用（对应知识目标）；
二是能用 JMeter（Summary Report / 聚合报告 / 开源监听器 / Dashboard）与 LoadRunner Analysis（Vusers 图、错误图、事务图、Web 资源图、网页诊断图）完成结果分析（对应技能目标）；
三是掌握了 CPU、内存、磁盘、进程、网络的瓶颈判定方法与关键阈值（Page Reads/sec>5、CPU>90%、磁盘转移>60ms、Private Bytes 查内存泄漏等），并按"事务→响应时间→TPS 曲线→资源"的顺序综合得出性能结论（对应技能/素养目标）。至此，性能测试模块（实验17~22）全部完成：从需求分析、JMeter/LoadRunner 脚本开发、场景设计与运行到结果分析，形成完整闭环。

22.6 作业提交¶

提交地点：吾爱作业网
提交资料：
- JMeter 聚合报告截图；
- LoadRunner Analysis 事务图（TPS、平均响应时间）截图；
- 系统资源监控截图 + 瓶颈分析结论。
- 不会做时填写"心得感悟"（1~50 字）。

22.7 知识检测¶

[ ] （填空）JMeter 聚合报告中，表示"90% 请求不超过该时间"的列是 90% Line。
[ ] （填空）PerfMon 监控服务器资源时，被监控机需启动 ServerAgent，其默认端口是 4444。
[ ] （选择）压力不断加大时 TPS 曲线变化缓慢或平坦，最可能说明（）。
- A. 系统运行正常　B. 服务器开始出现瓶颈　C. 网络变快了　D. 用户数太少

查看解析

正确答案：B。压力加大而 TPS 不再上涨，说明服务器处理能力已达上限，很可能出现瓶颈；还需结合平均响应时间与资源指标进一步确认。

[ ] （填空）内存分析中，Page Reads/sec 超过 5 可判定存在内存问题。
[ ] （选择）全部 CPU 平均利用率（Total %Processor Time）超过多少说明处理器瓶颈？（）
- A. 50%　B. 70%　C. 90%　D. 30%

查看解析

正确答案：C。Total %Processor Time 超过 90% 说明处理器瓶颈（多 CPU 负载不均衡也视作瓶颈）。

本课相关资源¶

序号	资源名称	类型	说明
1	任务3.1 基于JMeter结果分析.pptx	课件	Summary Report、聚合报告、监听器、Dashboard
2	任务3.2 基于LoadRunner结果分析.pptx	课件	Vusers/错误/事务/Web资源/网页诊断图、资源分析

实验素材下载

点击下方链接获取本节课全部资源（含课件、任务清单、安装包等）： 🔗 夸克网盘