企业官网建设流程全解析

做性能测试，LoadRunner 只是前半场，真正的重头戏在 Analysis。跑完脚本、拿到结果数据之后，如果不会看 Analysis 里的图，那前面半天甚至几天的压测基本等于白干。我见过太多新手，一打开 Analysis 就只抓一张事务响应时间总表，看一眼平均值觉得还行，然后就开始写报告——结果一问系统瓶颈在哪、从哪一秒开始劣化、是服务器先扛不住还是数据库先报警，什么都说不出来。这是很典型的“只压测、不分析”问题。

Analysis 是 LoadRunner 的结果分析组件，它把压测过程中产生的所有时间戳、计数器、响应码、吞吐量数据整理成一张张图表，解决的核心问题只有一个：按时间维度对齐不同指标，帮人定位系统性能瓶颈“到底出在哪一层、什么时刻出现的”。这篇内容适合刚接触性能测试的工程师、也适合正在用 LoadRunner 但分析还在套模板的同行，我会把最常用的几类图表、关联判断的思路、以及平时容易踩的坑一次说清楚。

1. Analysis 在性能测试里的定位与数据逻辑

1.1 不分析图表的压测等于只做了一半

很多人对 LoadRunner 的理解停留在 Vuser 和 Controller：脚本写完、设置好虚拟用户、启动场景、看着压力打上去，然后等跑完收数据。这个流程没有错，但只覆盖了“制造压力”这一步。压测的目的是发现问题，而问题不会自动打印在控制台上，它藏在响应时间曲线、吞吐量走向、服务器计数器之间的关系里。

控制器里看到的最大并发数、Passed 数量这些只是中间结果。Analysis 做的事是把这些中间结果转成可推理的证据链。比如说，一台服务器在 200 并发时平均响应时间 2 秒，这个数字本身说明不了问题；但如果结合系统的 TPS 曲线、CPU 使用率曲线、内存占用曲线一起看，可能就会发现 2 秒是因为 CPU 在 150 并发时已经到了 95%，而不是数据库或者网络的问题。没有 Analysis 的图表，这个判断很难做出来。

1.2 图里数据从哪来的，先搞清楚时间轴

Analysis 图表里的每一个数据点，都可以追溯到压力机端的 Agent 和被测服务器端的计数器。Vuser 脚本运行过程中，LoadRunner 会以事务为单位记录开始时间、结束时间、事务状态；服务器端的监控数据则来自 Controller 配置的性能计数器，比如 CPU、内存、磁盘、网络，这些数据也是带时间戳的。

Analysis 的核心机制就是把两类数据统一对齐到同一根时间轴上。它把你跑场景的这段时间，通过“场景开始时间 + 偏移量”的方式映射成图表的横坐标。注意，这个时间轴不是自然时间的绝对时间，而是从场景启动开始起的相对时间。所以你在 Analysis 里看到的 00:00:00 往往是场景第一个虚拟用户开始跑的时刻，而不是凌晨零点。理解了这一点，后面分析响应时间突变、并发浪涌的原因时，时间对齐就不会搞混。

2. 最常用的几张核心图表逐个拆解

2.1 平均事务响应时间图：最基础但最容易被误读

这张图在 Analysis 里的入口是“Transaction Response Time”下的曲线图，纵轴是时间秒数，横轴是运行时长，图里每个事务一条线。它反映的是某类事务从请求发出到接收完整响应的总耗时，包括网络传输时间、服务器处理时间、数据库访问时间、客户端渲染时间（如果脚本里有定义）。

看这张图时需要注意，LoadRunner 默认给的是“平均值”。平均值这个东西，被极大值拉高的可能性非常大。假设一个事务共执行了 100 次，其中 99 次都是 1 秒以内，但有 1 次因为 GC 停顿花了 30 秒，平均值就会变成大约 1.3 秒，看起来还算正常，可实际上系统的响应时间体验已经出了问题。所以我一般会同时打开同一事务的 90% 响应时间图，或者直接在 Summary 报告中看 90 Percent 列。前者更直观，曲线形态更接近用户实际感知。

2.2 虚拟用户数图：看并发和响应时间谁先变

虛拟用户图就是场景里 Vuser 数量的变化过程，通常呈斜线上升、阶梯平稳、斜线下降的形态。这张图单独看价值有限，但它是分析“拐点”的重要参照物。

我习惯把 Vuser 图和平均事务响应时间图放到同一张表里做 Overlay 对比。观察并发数每增加一批，响应时间曲线是平缓上升还是瞬间跳变。如果虚拟用户数从 50 上升到 100 时，响应时间只从 1.2 秒变到 1.4 秒，说明系统余量还比较充裕；如果从 150 上升到 160，响应时间从 2 秒直接跳到 5 秒，那这 10 个并发增量很可能正好压到了某个资源的临界值。判断的标准不是“响应时间不能超过多少”，而是“响应时间开始明显偏离正常趋势线的那个点”。

2.3 吞吐量与每秒事务数图：判断系统处理能力

吞吐量图（Throughput）是各时刻服务器接收和发送的字节数，每秒事务数图（Transaction per Second）则是每秒成功完成的事务数。这两张图经常需要配对看。

每秒事务数上升、吞吐量也上升，说明系统正在接收压力并正常处理，属于健康状态。如果 TPS 涨不动了，但吞吐量还在涨，说明传输的数据量在变大但业务完成数没上去，通常意味着系统在返回大量缓存数据或者在做耗时操作，比如慢 SQL 查询拉回了大批记录。如果 TPS 直接掉头向下，但 Vuser 数还在增加，基本就是系统处理不过来，请求开始排队等待，这是即将崩溃的前兆。

以前我压测过一个订单查询接口，跑到 120 并发时 TPS 卡在 500 左右上不去，吞吐量却一直往上走。后来查数据库慢查询日志，发现接口触发的报表统计查询没有分页限制，每次把几万条历史记录查出来再在内存里聚合，网络包大了，业务成功数自然上不来。这就是吞吐量和 TPS 走向背离的典型案例。

2.4 HTTP 响应码汇总：别忽略数据库层以外的间接信号

Analysis 里有 HTTP Responses per Second 图，统计的是 1xx、2xx、3xx、4xx、5xx 的每秒出现次数。很多人只看有没有 500，却忽略了 4xx 和 3xx 的异常波动。

举个实际例子，压测一个带有登录态的接口，并发升高后出现了大批 302 跳转。表面上看跳转是正常的，但再查日志发现，跳转是因为部分请求的会话过期后被重定向到了登录页，这部分请求虽然状态码是 302，但实际上并没有完成核心业务操作。如果把这类请求当成成功事务，TPS 统计就会虚高，结论也跟着跑偏。因此看响应码图时不光要看错误数量，还要结合业务成功条件来定义“事务通过”的标准，比如断言里要校验返回内容中是否包含业务成功标志，而不是只看状态码。

3. 系统资源图：把瓶颈固定到具体服务器层

3.1 系统资源图怎么解读才是有效看数

运行场景时，通过 Controller 的“Run-Time Settings -> Monitoring”配置 Windows 或 Unix 计数器，Analysis 里就能生成 Windows Resources / Unix Resources 图。常见的可配置计数器包括 CPU 使用率、内存可用字节、磁盘队列长度、网络接口每秒字节数。

判断 CPU 瓶颈时不能只看 CPU 总体占用率，最好把 Processor Time 和 Processor Queue Length 一起看。处理器队列长度的合理上限通常建议不超过 2 乘以逻辑 CPU 核数。如果队列经常大于这个数，说明线程已经吃不消，即使 CPU% 显示 80% 也要警惕可能存在的线程饥饿或锁竞争。内存方面，Windows 下要关注 Available Bytes 和 Pages/sec，如果可用内存持续下降并且换页频繁，说明内存不足，系统可能开始用磁盘虚拟内存兜底了。

磁盘问题容易被忽略。压测时如果发现响应时间曲线是“有节奏的锯齿形”，优先看看 Disk Time 或 Disk Transfers/sec。之前压一个文件上传服务，事务平均响应时间每 20 秒往上跳一下，看 CPU 和内存都很正常，最后看磁盘图，发现写入队列一直处于积压状态，日志盘的 IO 吞吐被上传文件的写操作占了，数据和日志共盘导致随机读写互相干扰。把日志目录移到另一块独立磁盘后，锯齿现象立刻消失。

3.2 Web 服务器层指标：跑 Web 压测必看的图

对于基于 HTTP 的 Web 系统，Analysis 里还有 Web Resource 图表组，里面包含 Hits per Second、Pages per Second、Connections 这些指标。Hits per Second 是每秒请求点击数，它和 Throughput 的区别在于一个偏请求数量、一个偏流量大小。

压测时建议把 Hits per Second 与平均事务响应时间叠着看。点击率上升但响应时间跟着上升，说明服务器请求处理链路上有瓶颈；点击率在某个阈值附近停滞，但响应时间还在涨，说明瓶颈可能已经转移到后端，而不是网络入口。还可以关注 Connections 曲线，如果连接数持续增长且没有回落，很可能存在连接未释放或者连接池被耗尽的问题，这种状态往往会表现为事务排队，但系统资源看着并不高。

3.3 数据库层指标不属于 Analysis 默认项，但要从数据趋势推断

严格来说，LoadRunner Analysis 里没有直接的数据库图表（除非用数据库协议的监控器），但是数据库的问题常常会在应用服务器的等待时间上留下痕迹。比如平均事务响应时间主要花在 Server 端，同时应用服务器的 CPU 开销很低，这大概率是数据库查询阻塞或者数据库锁等待。

通过 Analysis 中的“事务分解图”（Transaction Breakdown Tree）可以看事务内部各子步骤耗时。举个例子，一个登录事务被拆成 sent request、first buffer、received response 三段。如果 first buffer 时间占了总响应时间的 80% 以上，意味着服务器端从接到请求到开始返回响应之间，处理耗时很长；这个区间里发生的可能是应用逻辑处理，也可能是数据库查询。结合应用服务器的 CPU 空闲来判断，就能把疑问引到数据库层。确定后再去数据库端开慢查询日志或者活动会话监控，就可以做实判断。

4. 图表之间怎么关联分析：定位瓶颈的实操流程

4.1 从“响应时间变慢”切入，画出排查决策链

我习惯的分析流程是：先看趋势，再找拐点，然后顺着时间轴对表。举个例子，压测场景持续 30 分钟，前 10 分钟虚拟用户从 0 逐步加到 100，平均响应时间稳定在 1 秒；第 15 分钟开始响应时间爬升到 3 秒；第 20 分钟以后直接超过 10 秒。

这时候不要急着下结论。先把 Vuser 图、TPS 图、CPU 图、内存图、磁盘图全部拖到同一时间轴上看。如果响应时间在第 15 分钟起开始升，同时 TPS 从 800 掉到 400，CPU 整体占用率保持 85% 上下浮动，但队列长度从 2 一路涨到 12，基本可以判断是 CPU 处理能力饱和，请求已经排队了。如果 CPU 占用率只有 30%，TPS 却在掉，那问题就可能出在锁等待、数据库或者外部服务依赖上。

4.2 用“三道关”的方式判断是容量问题还是代码问题

第一道关看曲线形态：正常系统在压力递增时响应时间应该是缓坡上升，而不是悬崖式跳变。跳变往往对应资源耗尽、线程池耗尽、连接池满等容量硬顶。

第二道关看资源饱和度：CPU 超过 80% 或队列长度超标，优先考虑扩容或优化热点计算；内存持续下降，考虑对象生命周期和 GC 配置；磁盘繁忙，优先分析日志和 IO 竞争。

第三道关看应用层信号：如果从图表里找不到任何资源接近饱和的迹象，大概率要回到代码层面去查锁、查慢 SQL、查远程调用超时。我曾遇到一个场景，CPU 不过 20%，TPS 却随着并发量上升明显下降，最后查代码发现了某个接口里对共享缓存对象做了全量遍历，多个请求之间互相等待锁释放，问题体现在响应时间上，资源计数器却全部好看。

4.3 快速定位瓶颈的小技巧：用 Reason 按钮和时间区间缩放

Analysis 图表窗口里有一个“Reason”功能，右键点击图表选择 Reason，工具会自动分析当前图表中异常的区域并给出可能的原因描述，比如事务响应时间在特定时间点升高、同时页面浏览量下降等等。它给出的结论不一定完全准确，但能作为排查的提示起点。

另外要会用右键菜单里的“Zoom In”和“Set Filter”，把时间轴缩放到你关心的那一段。比如发现第 18 分钟出现一个明显的响应时间尖峰，直接从大图上框选那几分钟，再叠加 CPU 和网络计数器，重点观察这 3 分钟的详细趋势。很多性能瓶颈不是全程都存在，而是阶段性出现，不缩时间窗很容易被大范围的曲线平均值冲淡特征。

5. 常见陷阱与排查经验实录

5.1 只看平均值不看百分位，是最常见的问题

性能分析里有个不成文的习惯：平均值是给管理层看的，百分位值是给技术人员看的。平均值可以掩盖长尾问题，90 百分位或 95 百分位能更准确地反映大多数用户的实际等待时间。

如果在 Analysis Summary 报告里发现 90 Percent 远大于 Average，比如 Average 1.2 秒、90 Percent 6.5 秒，说明系统存在少量超级慢请求，拉高了长尾分布。这种情况要重点找慢请求的触发条件，比如是不是某些特定参数组合触发了复杂查询、是不是部分时段发生了 GC、是不是个别服务器实例负载不均。只修平均值不修长尾，压测报告发出去后线上用户反馈照样说卡。

5.2 图上时间轴和实际操作时间对不上

前面说过，Analysis 的时间轴是场景相对时间。压测过程中如果临时手动停掉部分虚拟用户或者调整了 Ramp Up 策略，在图表上看就是某个时点突然出现了一条垂直升降线。如果感觉曲线形状和场景配置对不上，优先检查场景设置里的 Ramp Up / Ramp Down 时间、Pacing 设置以及脚本中的思考时间。

还有一类时间对不上的情况是时区问题。Controller 所在机器的时区和被测服务器不同，导致系统资源图里的时间戳和 Vuser 事务图的时间偏移了几个小时。这种情况下，不要用北京时间去对应资源图的时间轴，而要以场景启动的相对时间基准为准，或者在做监控配置时直接统一用 UTC 时间记录。

5.3 并发数设置得很大，但 TPS 很低，图里到底谁在说谎

这个现象在压测里很常见，尤其是带思考时间（Think Time）的脚本。虚拟用户 300 个，TPS 却只有几十，原因可能不是系统弱，而是虚拟用户大部分时间都处于“发呆”状态，真实打到服务端的请求密度并不高。Analysis 里的 Vuser 图显示的只是在线虚拟用户数，不是活跃请求数。

要想看图识别这个陷阱，就看吞吐量和 Hit 曲线是否与 Vuser 曲线同步。如果 Vuser 涨了，吞吐量也同步上涨，说明脚本产生的负载密度正常；如果 Vuser 已经很高，吞吐量却始终平着走，那就要检查脚本里是不是有过多思考时间、集合点是否有效、或者预热数据不足导致每条请求都在等待。还有一点容易被忽略：如果脚本里写了同步点（Rendezvous），大量虚拟用户会集中在同一个时间点发起请求，在图上会看到很尖的并发刺，这种刺不能直接当成系统的平均并发处理能力，要用更长时间窗口的均值来判断。

5.4 压测结果图全部正常，却还是慢，这是最坑的一幕

有时候图表看起来一切正常：响应时间平稳、TPS 稳定、资源占用不高，可线上就是一直有人反馈慢。这时候要反思一个问题：压测的场景到底像不像真实业务？

如果脚本里所有的请求都是无状态的简单查询、没有用户登录态、没有复杂业务流转、没有文件上传下载，那压出来的结果几乎必然好看。这种情况下 Analysis 图表没有“问题”可分析，不是系统没有瓶颈，而是压力没有到达瓶颈。解决方式不是改图表，而是重新设计负载模型，比如增加真实业务比例、加入异常参数、延长压测时长、引入背景流量等。Analysis 再强大，它只能分析已经模拟出来的流量，没法预测你没压到的路径。

6. 报告导出与后续复用

6.1 自定义图表布局，打造适合自己团队的分析模板

Analysis 允许把多个图表拖拽到同一个页面，自定义布局后存为模板（.lra 文件）。我建议按团队需求建一套固定的分析模板，比如第一页放总体摘要和几个核心事务曲线，第二页放 Vuser、TPS、吞吐量叠加图，第三页放系统资源图，第四页放错误率相关的图表。这样每次压测完直接套模板看数，不用重新拖拽组装。

在自定义视图时，右键单击图表里的指标项可以设置纵轴刻度范围。响应时间图如果默认从 0 到 5 秒，而你的尖峰是 30 秒，可能会被“压”得看不出形态。把纵轴范围调大或者改成对数刻度再观察，能更明显地看出劣化趋势。

6.2 报告给不同角色看，重点图各不一样

Analysis 生成的 HTML/PDF 报告，不要一股脑全部丢出去。给项目负责人看，主要提供 Summary 报告中的最大并发、平均 TPS、平均响应时间、90 百分位和错误率，配上资源基线走势即可。给研发看，则要附带各事务响应时间分解图、吞吐量与 TPS 关联图、资源图的时间段标注，最好标出“第 X 分钟开始劣化”的具体时间窗和对应的系统表现。

报告中建议加一段“结论与建议”篇幅，直接写清楚发现的瓶颈点、可能的根因方向和下一步验证方案。表格形式比叙事式陈述更清晰，例如“时间窗、指标表现、可能原因、建议动作”四列表格。真正的分析报告价值是把疑问变成下一步可执行的动作项，而不是堆图。

我个人在实际操作中的体会是，Analysis 的大部分功能并不复杂，难的是在看图时保持提问意识：看到曲线先问自己，这个指标和哪个指标关联最紧密；看到拐点先定位时间窗，再把其他计数器往同一个时间窗上拉；看到结论先找反例，看看有没有别的解释能推翻自己。压测分析本质上就是一个假设、验证、再假设的过程。希望这篇内容能帮你在 Analysis 里少走一些弯路，真正把图表数据变成能指导系统优化的有效信息。