企业官网建设流程全解析

跑完一轮并发测试，LoadRunner自动弹出Analysis报告窗口，左边一列图节点，右边密密麻麻的曲线。很多人这时候习惯性截个Summary发给群里，说一句“压测跑完了，系统扛得住”，然后就没有然后了。说实话，我见过太多这样的场景——不是大家不想深入分析，而是面对那些图不知道从哪下手，不知道每根曲线背后在说什么，更不知道哪张图能回答“系统到底还能扛多少并发”。

这篇文章就把Analysis里最常用、也最容易误读的几张图拆开讲一遍：Summary报表、Vuser图、Transaction Response Time、Throughput与Hits、Error Statistics，以及Web Page Breakdown。每张图我都会讲它到底在统计什么、常见的误解是什么、怎么和别的图组合起来定位瓶颈。适合刚接触性能测试的开发、测试同学，也适合那些脚本已经能跑通、但一到分析阶段就卡壳的朋友。图表只是手段，最终要回答的无非三个问题：系统还能扛多少并发？哪里先顶不住？下一步改什么？

1. 一张Summary报表先定基调：四个必看字段与三个误读

1.1 打开Analysis后的第一件事：先把Summary的四组数字抄下来

Analysis打开后默认停在Summary页，这一页信息密度很高，但绝大多数人只看一眼“Average Response Time”和“Total Errors”。我建议你每次压测结束，先把下面几组数字记到本子上，作为后续所有图表分析的锚点。

这一步骤不是让你直接下结论，而是建立“这次压测到底做了什么、整体是什么量级”的基线。比如Total Hits如果远低于设计值，那就先别急着分析性能，大概率脚本没跑完整或提前被停了；Average Throughput如果异常低，也要回看脚本是不是所有请求都集中在一个极小的接口上。基线不对，后面所有曲线都是错的方向。

1.2 平均响应时间是最容易被误读的“平均工资”

Average Response Time是Summary页最显眼的数字，也是我最不信任的数字。它的问题和“平均工资”一样：少数几个极大值会把整体数值拉高，而绝大多数用户的真实体验可能完全不是这个数。

举个例子，某个查询接口压测结束后Summary显示Average Response Time是0.8秒，看起来不错。但如果你去Transaction Response Time图里把最大响应时间调出来，会发现最大单次响应到了8秒，90%的请求其实都集中在0.4秒左右。这就意味着有极少数请求经历了严重的排队或超时重试，它们把平均值硬生生拉高了。这种长尾在Summary上完全看不出来，它只告诉你“平均还行”，不会告诉你“有一部分用户已经卡到想骂人”。

所以我的习惯是：Summary里的Average Response Time只用来做快速体检，真要判断系统是否达标，必须去事务响应时间图里看分布，最好用90%线、95%线甚至99%线来评估。如果压测工具界面没有直接显示百分位，就把Analysis结果导出成CSV，用Excel的PERCENTILE函数自己算一下。这一步很快，但对结论的影响非常大。

1.3 错误率低不代表安全，关键是错误发生在哪个时间窗

Summary里的Errors数字如果显示为几十条，而整个压测跑了几个小时，错误率可能只有0.5%，很多人就会忽略它。但平均错误率低不代表没有风险。我在实际压测中见过不少这样的情况：前一个小时零错误，后二十分钟突然连续报错，最终平均下来错误率不到1%。这种“最后阶段集中报错”往往意味着系统已经到达某个资源上限，开始拒绝新连接或超时了。

判断方法很简单：把Errors per Second图拉出来，看错误的分布形状。如果错误点均匀散布在整个时间轴上，可能是脚本偶发问题或网络闪断；如果错误集中在某一段，尤其是和并发数爬升到高位的时间段重合，那基本可以断定系统在那个点已经顶不住了。总结一下，Summary页的职责是“发现问题信号”，不是“证明系统没问题”。一旦发现平均响应时间、错误数有异常信号，就该进入下面的单图分析。

2. Vuser图存着三个不同的“并发量”：Running、Finished与设计目标

2.1 Vusers图到底有几条曲线，分别代表什么

LoadRunner Analysis里的Vusers图，很多人默认它就是“并发量随时间变化的曲线”，然后拿它和响应时间曲线做对比。这个理解大方向没错，但少了一个关键认知：图上其实有好几条曲线，含义完全不同。

通常你在Vusers节点下能看到这样几条线：Vusers、Running Vusers、Finished Vusers。Vusers是累计启动的虚拟用户总数，一直往上走；Finished Vusers是累计完成的用户数，也一直往上走；真正值得关注的是Running Vusers，它才是某一时刻“正在执行脚本逻辑”的用户数。大部分压测脚本里都有思考时间（Think Time）和迭代间隔（Pacing），用户启动后可能正处于思考时间挂起状态，并没有向服务器发送任何请求。所以Running Vusers曲线比“设计并发数”更能代表真实请求压力。

另外，Ramp Up阶段的Vuser曲线通常是阶梯状或锯齿形的。你设置了每30秒增加5个用户，图上就会呈现阶梯；如果脚本迭代时间不同步，曲线又会出现锯齿。看到这种形状不用慌，那是调度器的正常表现，不代表系统有问题。真正要注意的是：Running Vusers的数量是否和设计值大致吻合，以及用户启动过程中有没有大量报错。

2.2 怎么用Vuser图找系统拐点：把Running Vusers和响应时间放到同一个时间轴

Vuser图单独看价值有限，它必须和Transaction Response Time、Throughput配合使用，才能回答“并发到多少的时候系统开始变慢”。

具体操作上，我在Analysis里习惯把Running Vusers曲线和事务响应时间曲线叠加显示。比如某系统压测从50个Vuser开始，每5分钟增加25个，最终到达200个。在叠加图里你能清晰看到：Vuser数在120以下时，响应时间基本稳定在1秒左右；一旦Vuser数跨过120，响应时间开始明显爬升，从1秒跳到2秒多；到180的时候，响应时间已经接近5秒。这个120左右的位置就是系统的体验拐点。

顺便提醒一句，Ramp Up速率本身也会影响曲线形态。如果启动太快，比如一分钟内从0直接拉到200个Vuser，连接拒绝类错误可能一上来就出现，响应时间也会瞬时拉高。这种情况下先别急着下“系统容量不行”的结论，很可能是压测本身的压力曲线设计得太激进，把系统在启动阶段的瞬态问题放大了。

2.3 退潮阶段别跳过：用户停止时的曲线藏着稳定性信息

很多人的分析习惯是盯着Vuser爬坡和峰值阶段，用户开始减少后就直接跳过。我建议你把退潮阶段也看一遍，因为系统恢复能力同样是性能的一部分。用户并发从高位逐步降下来时，响应时间是否跟着回落？错误是否还在持续产生？如果并发已经降到很低，响应时间却依然保持在高位，说明系统内部可能还有线程池排队、连接池未释放或后台任务积压，这种“恢复慢”的现象在长时间压测后尤其常见。

这条经验帮我抓到过不少问题：某次压测峰值并发300，所有指标看起来都还能接受，但压测结束后Running Vusers已经降到20，接口响应时间却还在3秒以上。后来查出来是数据库连接池在高并发下被耗尽，连接长时间无法归还，系统处于半瘫痪状态。如果只盯着峰值看，这个问题很容易被忽略。

3. 响应时间图不是一条线的故事：平均值、百分位与事务分解

3.1 Transaction Response Time图的三种打开方式，各解决什么问题

Analysis里的Transaction Response Time节点下通常有好几个子图，很多人一上来就看Average Transaction Response Time曲线，其他的就不管了。实际上这几个子图各有用处，取舍取决于你现在要回答什么问题。

Average Transaction Response Time曲线最适合看趋势，比如响应时间是不是随并发爬坡而上升，有没有突变点；Transaction Performance Summary则以表格形式给出每个事务的最小值、平均值、最大值和标准差，适合横向对比不同事务之间的差异；Transaction Breakdown Tree则用来拆解单个事务内部各个阶段的耗时，适合定位“到底慢在哪一步”。我的建议是：先用Summary表格找到最慢的、波动最大的事务，再用曲线确认它的时间趋势，最后用Breakdown拆解它的内部耗时。三步做完，一个事务的响应时间问题基本就能说清楚。

3.2 平均值、最大值、标准差：到底以哪个为准

判断响应时间是否达标，不能只看平均，也不能只看最大。平均值会被长尾污染，最大值则容易把偶发抖动当成系统常态。真正有参考价值的是百分位分布和标准差。

百分位解决的是“绝大多数用户感受如何”的问题。比如SLA要求“95%的登录请求在2秒内完成”，那你就应该看P95，而不是平均响应时间。标准差解决的问题是“响应时间稳不稳定”。两台接口平均响应时间都是300毫秒，一个标准差20毫秒，一个标准差200毫秒，前者的体验非常稳定，后者则会让用户明显感觉到“有时候快有时候慢”。遇到标准差特别大的事务，我一般优先排查GC暂停、数据库慢查询、网络重传、连接池排队这四类问题，因为它们最容易造成抖动。

分析时如果工具的默认图表看不到百分位，可以把结果导出去自己算。我常用做法是导出CSV后按事务名称过滤，再用Excel的PERCENTILE.INC函数算P90、P95、P99。这个数据比平均值更能支撑你写压测报告里的SLA结论。

3.3 事务分解：一个登录事务慢，到底是慢在连接还是服务端处理

到了Breakdown这一步，问题从“哪个事务慢”细化成“事务里的哪个环节慢”。一个典型的登录事务，在Web Page Breakdown里会被拆成DNS解析、建立连接、SSL握手、发送请求、等待首字节、接收响应等阶段。

我通常优先看两个地方的耗时：一个是Time to First Buffer，一个是Download Time。Time to First Buffer长，说明服务端处理请求并返回首个字节的速度慢，问题多半在后端逻辑、数据库或缓存；Download Time长，说明响应体本身很大或者带宽受限，简单页面几百毫秒内就能下完，如果下载阶段长时间占大头，就要检查页面引用了多少个静态资源、单文件有多大。至于Connection或SSL握手阶段如果特别长，那就要往网络链路、TCP连接队列、TLS协商开销上想。

这里有个实操前提：Web Page Breakdown并不是默认就会记录所有子资源的详细耗时，你需要在脚本的运行时设置里提前开启组件分解能力，否则Analysis里这一项可能是空的或者只有主页面数据。所以压测之前最好就把这项打开，不然跑到分析阶段才发现没数据，还得重新跑一轮。

4. Throughput与Hits的搭配分析：吞吐量拐点才是容量极限

4.1 先分清Throughput和Hits的单位和含义

不少压测报告把Hits per Second和Throughput混为一谈，或者只写其中一个就下结论。这两个指标的单位完全不同：Hits per Second是每秒请求次数，衡量的是业务请求的频率；Throughput是每秒传输的字节数，衡量的是流量大小。请求数高不一定吞吐量大，因为每个请求返回的数据可能很小；同样，吞吐量很高也不代表请求数多，因为可能涉及大文件下载。

实际分析时，我会把这两个曲线放在一起看，然后用四种组合来判断系统状态。请求数上升、吞吐量跟着上升，说明系统在处理更多业务，属于健康的扩展；请求数上升、吞吐量却平着不动，可能是缓存命中导致返回体变小，也可能是部分请求已经开始失败、只返回了简短的错误信息；请求数不变、吞吐量明显上升，多半是某个响应体变大或缓存失效；请求数下降、吞吐量反而上升，可能出现了大量下载类型的请求或重试行为。每一种组合背后对应的系统状态完全不同，单看其中一条曲线根本区分不出来。

4.2 找吞吐量拐点：三线合一的读法

找系统容量极限，我很少只盯着响应时间判断，而是把Running Vusers、Throughput、Transaction Response Time三条线放到同一时间轴上看。

拿一个查询接口的压测举例。Vuser从50增加到100的过程中，吞吐量从2MB/s涨到4MB/s，响应时间稳定在1.5秒，说明系统还处于线性扩展区；Vuser继续增加到150，吞吐量只涨到4.5MB/s，涨幅明显变小，而响应时间已经涨到3秒。这时候基本可以判断，系统的处理能力拐点大约在100到120个并发之间。超过这个范围，继续加用户只是在堆排队时长，吞吐量不会再跟着涨。这个“吞吐量停止增长、响应时间继续恶化”的交叉位置，就是容量规划的参考值。

需要注意，吞吐量封顶不一定全是服务端的计算瓶颈，也可能是网络带宽到了上限。如果是带宽瓶颈，你会看到Throughput曲线非常平，但服务端CPU和内存监控可能还有余量。这种时候要把网络监控数据拿过来对照，区分是“机器处理不动了”还是“数据传不出去了”。

4.3 为什么只看Throughput容易误判系统能力

只看吞吐量判断系统强弱，经常得出反直觉的结论。举个例子：两个压测场景，一个是高缓存命中率的商品详情接口，几乎每次请求都从Redis里取数据，返回体很小，吞吐量可能只有几百KB/s；另一个是大文件下载接口，单次响应就几MB，吞吐量轻松到10MB/s。如果只对比吞吐量，会以为第二个接口性能更好，但实际上第一个接口的业务处理能力、每秒请求数可能远高于第二个。

指标必须和场景绑定。压测的是业务接口，判断能力的核心指标是请求成功率、响应时间分布和每秒事务数；压测的是文件传输类接口，吞吐量才更有参考价值。继续深挖的时候，应先用Throughput和Hits的组合确认“是不是请求本身出了问题”，再回到事务分解里看细节。两条曲线配合使用，永远比单看一个数字靠谱。

5. Error报表和Web Page Breakdown：红色数字背后的两层排查

5.1 Errors per Second和Error Statistics先看类型，再看分布

压测过程中出现错误不可怕，可怕的是看到错误数就直接在报告里写一句“存在少量报错”，完全不区分错误类型。Analysis里的Errors per Second显示错误随时间变化的分布，Error Statistics则按错误信息和脚本位置聚合，两者要配合看。

常见的错误大概分这么几类：Connection reset或Connection refused，通常指向连接池耗尽、TCP队列满、服务重启或防火墙干预；Timeout类错误，多半是服务端处理速度跟不上，请求在等待过程中超过超时设置；DNS Error，指向域名解析链路故障；HTTP 5xx错误，则需要回到服务端日志确认是限流还是应用异常。每一类错误的排查方向完全不同，把它们混在一起统计会严重误导判断。

特别提醒一点：不要一看超时错误就把脚本里的超时参数调大，觉得“让请求多等一会儿就能过”。调大超时只是让错误出现得更晚，并不会解决后端处理慢的问题。压测中出现超时，首要任务是去查后端在那个时间点的线程状态、数据库等待和GC情况，而不是改脚本参数。

5.2 Web Page Breakdown的每个阶段代表什么

Web Page Breakdown是把一个页面请求的完整生命周期拆成多个阶段，我用一个寄快递的类比解释它：DNS Lookup是查地址，Connection是拨通电话，SSL Handshake是双方确认密语，Time to First Buffer是对方开口说第一句话的间隔，Download Time是对方把整段话说完的时间，Client Time则是你听完之后自己消化信息的时间。

哪个阶段慢，问题方向完全不同。DNS Lookup长，优先查本地DNS配置和解析服务器；Connection长，关注网络链路、TCP连接队列和防火墙会话限制；SSL Handshake长，考虑TLS协商开销是否过大，需不需要启用会话复用；First Buffer长，说明后端服务处理慢；Download Time长，则指向响应体过大或带宽不足。阶段定位做得越细，后续找后端日志和系统监控数据就越有针对性。如果压测的目标是接口而不是完整页面，可以关闭子资源统计，只保留主请求的分解数据，这样更贴近真实接口场景。

5.3 实战组合：一个登录接口的定位过程

用一个虚拟场景把这套组合走一遍。假设压测一个登录接口，摘要显示平均响应时间1.8秒，错误率约1%，表面看不算太差。打开Error Statistics后发现错误基本是Timeout，而且集中在并发数超过150之后。再看Web Page Breakdown，发现SSL Handshake平均耗时600毫秒，First Buffer要1.1秒，明显比同环境下的其他接口高。

这时候我基本会形成两个候选结论：一是新建连接太多，TLS握手开销把平均响应时间撑高了；二是后端在参与校验登录时确实处理得慢。下一步就是回服务端看连接数监控和登录接口的调用链数据，确认到底是网络层握手瓶颈还是后端逻辑瓶颈。整个过程里，任何一张图单独说话都站不住脚，必须组合起来才能形成完整证据链。这也是我一直强调“分析不是看图说话，而是用图找证据”的原因。

6. 一套可复用的Analysis走查顺序：从50个并发到500个并发都按这个节奏来

6.1 五步走查清单，每一步要产出什么结论

看完这么多图之后，你可能会觉得信息量太大。这里我整理了一套固定走查顺序，每次压测结束都按这个节奏来，既能避免漏看关键信息，也能保证结论有条理。

第一步，Summary定基调。记录Vuser规模、Total Hits、Average Response Time、Errors四组数字，确认本次压测执行符合设计。第二步，三线对齐找拐点。把Running Vusers、Transaction Response Time、Throughput三张图叠加，确认响应时间开始恶化和吞吐量停止增长的位置，估算容量拐点。第三步，Top事务分解。从Transaction Performance Summary里挑出平均耗时最大、标准差最大的事务，用Breakdown拆解内部阶段，定位是连接层、传输层还是服务端逻辑问题。第四步，错误图锁定时间窗。用Errors per Second和Error Statistics确认错误类型和集中时段，判断是否和拐点重叠。第五步，结合资源监控下结论。如果压测期间采集了CPU、内存、磁盘、数据库连接等数据，回到对应时间点做交叉验证，得出结论时要写清楚“瓶颈指向什么、依据是哪张图的哪个区间”。

这套顺序对小并发、大并发都适用，区别只在于每步的侧重点。50个用户的冒烟压测里，所有曲线可能都平稳，那就重点做第三步和第四步，看偶发错误和单个慢事务；200到500并发时，三线对齐的拐点会非常明显，容量判断就靠第二步；上千并发的场景则更建议按业务模块拆开分析，单张图看全局已经不够准确了。

6.2 不同负载规模下，读图重心要学会切换

压测规模不同，分析重心完全不同。低并发阶段，系统还没到资源瓶颈，响应时间曲线会很平，这时候把大量时间花在找拐点上意义不大，更应该关注的是那些“个别慢请求”到底为什么慢——也许是一次GC停顿，也许是一条偶发慢SQL。我会把Transaction Breakdown和Error Statistics作为重点，因为低并发下还能出问题，多半是隐藏的代码缺陷或依赖抖动。

中高并发阶段，系统开始进入排队区，拐点成为核心产出。这时候我会反复确认三线对齐的拐点并发数，并且特别留意退潮阶段是否恢复正常。如果峰值表现尚可，但结束后长时间不恢复，比峰值直接打挂更危险，说明资源释放机制有问题。到了极高并发阶段，单张图的全局视角已经不够用，需要按业务模块拆分事务、单独压测、单独看趋势，这样才不会让瓶颈互相掩盖。

6.3 从图到建议：压测结论怎么说才不挨打

分析完之后，最终都要落到一句能指导决策的结论上。我最不想在压测报告里看到的话就是“系统整体稳定，建议持续观察”——这句话没有任何一图一数支撑，别人也没法据此做任何决定。尽量写成这种有依据的句式：“在并发数低于120时，登录接口平均响应时间1.0秒，错误率为0；当并发达到150，响应时间超过3秒，吞吐量不再增长，瓶颈指向Web服务器到数据库之间的连接池配置，建议优先扩容连接池并进行一次慢SQL治理。”

这种写法把结论锚定在具体并发数、具体指标、具体瓶颈上，后续优化完再压一轮，直接对比数据就知道措施有没有效。最后再分享一个我自己的工作习惯：每次压测结束后，把Analysis的Summary页和核心图导出成PDF或CSV存档，和上一轮结果对比。如果拐点往前挪了，说明系统在变差；如果拐点往后推了，说明优化有效。图表分析的意义不在于当时看完得出结论，而是让每一次改动都有前后对照的量化证据。