企业官网建设流程全解析

1. 先立个框架：性能指标不是一个点，而是一条链路

1.1 别急着看数值，先回答“这些指标给谁看”

我做了这么多年性能测试，发现最容易翻车的不是不会压测，而是拿到结果不知道该怎么解读。你给领导汇报，说TPS有1200、平均响应时间180毫秒，领导一拍桌子说很好，但上线第二天用户投诉页面转圈——为什么？因为指标选错了，没对准“用户感受到的那个东西”。

性能测试里的指标，归根到底是给两类人看的：一类关心体验，一类关心成本。用户不关心你的CPU是多少核，他只关心“这个操作到底卡不卡”；开发关心的是“到底哪一段代码慢了、哪个资源被打满了”。所以一开始就要把指标分到不同视角去组织，不能混在一起贴截图。

我一般把指标体系分成三层：

这三层不是各看各的，而是必须能对上账。用户层说响应时间慢了，应用层要能拿出TPS和错误率的证据，系统资源层则要指出是哪个资源到了上限。指标拆到这个粒度，才叫“完整”，不然你只是在罗列数字。

1.2 响应时间、TPS、资源利用率：性能指标的“铁三角”

我记得带新人时最爱打一个比方：性能指标就像看一个人跑步。响应时间是他的百米成绩，决定单次体验；TPS是他的步频，决定整体产出；系统资源利用率则是他的心率和耗氧量，决定这套跑法能维持多久。

只看百米成绩，可能忽略了这是在操场冲刺而非在马拉松后半段；只看步频，可能忽略了已经气喘吁吁，马上要崩。系统也一样，TPS很高不一定健康——有可能是靠耗尽线程池、频繁GC、把CPU打到99%换来的，一旦流量再涨一点，系统直接雪崩。反过来，RT很漂亮也不代表能抗压，可能只是并发根本没压上去。

所以判断一次压测结果，正确的姿势是同时拿出三组数据：

• 时间维度：RT平均值、P90、P99、最大、超时率
• 容量维度：TPS、吞吐量、并发处理中的请求数
• 成本维度：CPU利用率、内存走势、GC频率、连接池饱和度

三者之间还有一种动态关系：随着并发升高，TPS先涨后平，RT前期平稳后期陡增，资源利用率逐步走高。那个“TPS不再上涨、RT突然抬头”的位置，就是系统的真实容量拐点。后面我还会专门讲这个拐点怎么找，它是容量测试的灵魂。

2. 应用层核心指标拆解：RT、TPS、并发数、错误率，逐个说透

2.1 响应时间：平均值的迷魂汤与百分位数的真相

响应时间是最基础的指标，但也最容易被“平均”骗。假设某个接口压测了1000次，999次都是200毫秒内返回，但有一次线程池被某个慢SQL拖住，让一个请求等了8秒。这时候平均响应时间被拉高到208毫秒左右，看着好像还行，但真实情况是：有0.1%的用户经历了8秒的白屏，这个体验已经足够让用户骂人了。

所以看响应时间，我几乎不看平均值，重点看百分位数：

• P50（中位数）：一半请求快于它，一半慢于它，反映典型体验。
• P90：我认为这是日常体验容忍线，90%的请求要在这个值以内。
• P99：长尾体验分水岭，直接反映极端场景下的稳定性。
• P999：用来抓偶发尖刺，如果P999明显高出P99一大截，基本能断定有间歇性阻塞，比如GC停顿、锁等待、连接池排队。

在实际操作中，JMeter的聚合报告里可以直接勾选百分位统计，也可以用CSV日志自行计算。我的习惯是压测时把响应时间按“事务名”分组，导出后写段脚本排序取值。举个例子：一万个样本排序后，第9900个样本的值就是P99。这个数只要比P50大三到五倍，就需要警觉了——说明系统并不是“均匀地慢”，而是有一定比例请求被明显卡住。

2.2 TPS、QPS和吞吐量：先把口径对齐再谈数值

TPS和QPS可能是性能测试里被滥用最严重的两个词。很多人混着用，但严格来说，TPS是“事务数/秒”，QPS是“查询数/秒”，吞吐量在不同场景下又可能是“每秒处理请求数”或“每秒传输字节数”。

关键问题是：一个事务往往包含多个请求。比如一个“下单”事务，脚本里可能先请求登录态校验，再请求商品详情，最后调用下单接口，一共3个HTTP请求。如果TPS是100，那实际的QPS至少是300。压测报告中如果只写TPS，不说明事务定义，别人根本无法复现你的口径。

我见过最坑的一次协作：A组用“单接口请求数/秒”对外报TPS=5000，B组用“完整业务流程事务/秒”报TPS=800，两边的系统其实是同一个，但汇报给管理层以后，管理层认为A组和B组数据矛盾，质询了一整周。后来我们定了统一规则：TPS必须基于脚本里定义的事务粒度，且必须把事务包含的请求数写进报告备注。否则所有指标都失去可比性。

另外要区分“工具侧吞吐量”和“服务端实际处理能力”。JMeter里显示的Throughput是客户端视角的每秒完成请求数；如果客户端本身成为瓶颈，比如脚本机器CPU打满、带宽不够，这个数值就不是服务端真实能力。压测之前先确认压力机资源占用正常，这个细节别忽略。

2.3 并发用户数：一个被大量测试设计带偏的指标

“并发用户数”这四个字误解之大，排得上性能测试前三。很多人以为100个线程就是100个并发用户，其实线程只是“模拟出来的操作者数量”，真正衡量系统压力的指标是“同时处于处理中的请求数”，或者说服务端同一时刻在处理的活跃请求数。

学过排队论的朋友应该知道Little‘s Law：系统中并发请求数 = TPS × 平均响应时间。举个例子：某接口TPS=100，平均RT=200ms（0.2秒），那么系统内同时处理中的请求大约就是 100 × 0.2 = 20个。也就是说，哪怕压测脚本开了500个线程，由于大部分线程在思考时间、延时、等待响应，真正砸到服务端的并发压力可能只有20个。这个数字远比“开了多少线程”更能说明系统负载。

反推一下：如果你想压出“服务端同时存在200个正在处理的请求”，在平均RT=0.2秒的前提下，TPS需要做到 200 ÷ 0.2 = 1000。那么压测脚本开多少线程合适？这不仅取决于目标TPS，还取决于脚本单次迭代耗时。通常的做法是先给一个估计值，跑一轮看实际TPS和RT，再按公式反调线程数。压测不是配好参数就躺平，而是要动态校准。

我还想多说一句思考时间。JMeter里可以通过Constant Throughput Timer或BeanShell实现思考时间，但很多人做接口压测时根本不加思考时间，把所有线程都置成“0等待、疯狂点击”。这样压出来的结果代表的是“极端最大压力”，不是真实用户行为。如果目标是评估用户体验，出了问题不要怪指标不准，先看看脚本里的思考时间是否符合真实使用习惯。

2.4 错误率：必须拆开看的五个类别

错误率是最终底线，但“错误率0.05%”这句话如果没有说明错误种类，等于没说。我习惯把压测中的错误分成五类，在断言和统计时全部分开：

1. 网络层错误：连接超时、连接重置、DNS解析失败。这类错误往往在系统过载时批量出现。
2. HTTP状态码错误：5xx、4xx。5xx接近“系统自己承认处理不了”，4xx则可能是参数问题。
3. 断言失败：接口返回200但业务结果不对，比如下单后订单号为空。这类最容易被忽略，也最影响真实业务。
4. 超时错误：客户端设置了超时阈值，请求没在指定时间内返回。这在压测中非常常见，是系统接近瓶颈的重要信号。
5. 业务规则错误：比如库存不足、余额不够。这类不是系统性能问题，应作为业务异常排除在性能指标之外，否则会污染错误率。

统计那一刻，我们通常要求总错误率低于0.1%，但更严格的做法是分别看“技术错误率”和“业务错误率”。如果技术错误率高于0.1%，就要排查服务端是否已经出现明显劣化；业务错误率即使高，也必须回头确认是否是测试数据问题。

2.5 超时与响应时间尖刺：平均值看不见的炸弹

有一次稳定性压测，前3个小时TPS平稳、RT漂亮，但从第4小时开始，每过30分钟就会出现一次P99从300ms跳到2秒的尖峰，平均响应时间只从180ms涨到220ms，乍一看完全没问题。后来通过监控时间线对齐发现，尖峰出现的时间正好是JVM触发Full GC的时刻。这个案例说明了为什么性能测试不能只看平均数，还要看时间序列上的“毛刺”。

处理响应时间尖刺的常用指标是“超时率”和“响应时间分布”。压测工具可以统计响应时间超过自定义阈值的请求百分比，比如“超过1秒的请求占比”。在JMeter中可以通过Duration Assertion设置阈值，把超过阈值的请求单独标记为失败，再统计其比例。我的建议是每个关键事务都设置两档阈值：一档是“体验容忍线”，比如1秒；一档是“不可用线”，比如3秒。这两档结果一条写进报告，能直接回答业务方“到底多少用户被卡了”。

3. 系统资源与中间件指标：CPU、内存、GC、连接池，如何和业务指标对上账

3.1 CPU指标：利用率不是越高越好，还得看是不是“忙得有价值”

系统资源指标是性能排查的第二落点。很多人一看CPU利用率到了90%就觉得性能好，其实要看这90%花在哪了。CPU时间可以分为用户态、系统态、等待IO、被抢占等几类。用top命令观察时，如果wa（IO等待）很高，说明CPU在等磁盘或网络返回，这种“忙”是虚忙，真实瓶颈可能在存储或网络。

我一般压测时会同步记录这么几组CPU相关数据：

• CPU总利用率：判断还有多少余量。
• 每个处理器的利用率：多核架构下可能出现单核打满、其余空闲，这时要怀疑热点线程或锁竞争。
• 用户态/系统态比例：系统态占比异常高，往往和系统调用、上下文切换有关。
• 平均负载（load average）：这个数要和CPU核数一起看，负载超过核数意味着有线程在排队，另一种角度看就是“并发处理中的任务”超出了CPU的容纳量。

有一次排查一个RT突增问题，TPS没降，CPU也只有40%，但load average高达16，机器是8核。通过sar和vmstat定位到进程上下文切换次数极高，最后揪出是压测脚本里某个函数导致线程频繁sleep和唤醒，把内核调度打爆了。所以CPU指标要看“全息图”，不能只看一个百分比。

3.2 JVM指标：Full GC就是长尾RT的头号嫌疑人

Java服务做性能测试，JVM指标基本是必修课。核心看四块：堆内存使用、GC次数、GC耗时、线程状态。

命令可以直接用JDK自带的jstat，比如：

jstat -gcutil 12345 1000 10

这个命令的意思是对PID 12345的进程，每1秒打印一次GC情况，共打印10次。输出里的FGC是Full GC次数，FGCT是Full GC累计耗时。如果压测过程中FGC快速增长，或者单次Full GC耗时超过几百毫秒，那意味着用户请求大概率出现明显的停顿——也就是我们在百分位指标里看到的RT尖刺。

另外要看的指标还有：

• 老年代使用率：如果压测后老年代持续上涨，回收完又涨，那就不能再自欺欺人地说“只是年轻代对象过多”，这通常是内存泄漏的前兆。
• GC吞吐量：即“非GC时间/总时间”。低于95%时就要警惕GC已经消耗了过多CPU。
• 线程数：Tomcat的当前线程数、忙碌线程数。如果忙碌线程始终等于最大线程数，说明线程池已经见底，后续请求只能排队，RT会加速恶化。

3.3 连接池和线程池指标：排队开始的那一刻，性能就开始劣化

线程池和连接池是服务端最容易发生“排队劣化”的地方。Tomcat的默认线程池配置再大也有上限，数据库连接池同样如此。当请求到达速率超过连接释放速率，队列里就会堆积等待者。

我在压测中常监控的指标包括：

为什么这些指标重要？因为连接池是典型的“临界资源”，一旦耗尽，后续请求不会立刻失败，而是在池子外面排队。排队时间会直接叠加进RT，于是表现是TPS不再上涨，但RT像坐了火箭一样往上冲。判断是否是连接池瓶颈，最简单的办法就是看等待获取连接的线程数量以及单次获取连接耗时。如果这两个指标与请求RT同步上升，基本可以锁定问题。

3.4 数据库指标：慢查询、锁等待、缓存命中率

业务系统性能瓶颈大概70%以上最终都能回到数据库。我在压测时，数据库机房需要同步盯的指标：

• 慢查询数量与耗时：打开慢查询日志，把压测时段内的慢SQL捞出来。不是所有慢SQL都影响性能，但如果在压测高并发时，同一类SQL反复出现在慢日志中，那它就是主要嫌疑。
• 锁等待事件：InnoDB的行锁等待时间、表锁等待次数。压测时最容易出现的是并发更新同一行时产生行锁竞争，造成RT被拉高。
• 连接数：数据库最大连接数是100或500，一旦打满，连接池等待时间飙升。这个问题在压测里出现频率极高。
• 缓存命中率：Redis这类缓存组件，命中率下降意味着大量请求穿透到DB，DB压力剧增。

从前有一个让我印象特别深的案例：接口压测时TPS一直上不去，服务端CPU低、连接池空闲、SQL单条很快，但RT就是高。后来查到数据库主从延迟严重，代码里有“写后读”逻辑，每次写完都要等从库同步，同步延迟直接加到了接口RT里。这类问题只盯着应用层指标永远找不到，必须把数据库指标拉出来对账。这也是我为什么一直强调：性能指标一定要覆盖“请求链路经过的每一层”。

4. 稳定性与业务可用性指标：有些指标要等压测跑完几个小时才看得见

4.1 稳定性测试盯三张趋势图

短期压测和长期稳定性压测看的指标不一样。短期主要看峰值能力，长期则要看变化趋势。我在稳定性测试里默认会盯三张趋势图：

1. 错误率趋势：错误率随时间逐步上升，说明系统在持续劣化。
2. RT百分位趋势：P99是否随时间缓慢上升，即使平均值很平稳。
3. 内存曲线：堆内存、非堆内存是否单调向上，垃圾回收后是否回不到基线。

拿内存来说，一个典型的模拟场景是：系统每处理一笔订单就创建一个对象并存入一个静态Map，key是订单号，value是订单详情。压测一开始内存正常，跑两个小时后老年代慢慢上涨，Full GC开始变频繁，最后OOM。如果你只跑15分钟负载测试，这个BUG永远不会暴露。所以稳定性测试的时间长度设定必须能覆盖一个完整的业务周期，而不是拍脑袋说“我跑30分钟吧”。如果线上有每小时定时任务，那至少跑3到4个小时；如果业务有日终对账，最好跑完整的一天。时间本身就是一种测试参数。

4.2 可用性指标：从错误码到“体验达标率”

说到可用性，很多人本能地想到“系统没有挂”。但业务视角的可用性比这严格得多。我参与过的一个电商类项目，把可用性定义为“5秒内完成下单”，只要超过5秒，就算这个请求体验不可用。也就是说，即使接口返回200，只要响应耗时超过阈值，就会被计入不达标请求。

由此可以定义两个关键指标：

• 成功率：成功响应数 / 总请求数。这个就是常规意义上的技术可用性。
• 响应达标率：在目标时限内返回的成功请求数 / 总请求数。这才是体验可用性。

计算可用性时，常见公式是“可用性 = (总时间 - 不可用时间) / 总时间”。压测场景下，可以用成功请求占比近似，但更严谨的做法是把“错误请求”和“超时请求”都算入不可用时间窗口。假设线上可用性目标是99.9%，意味着一年内故障时间不能超过8.76小时，折算到单次压测场景，能不能容忍0.1%的失败，要从业务目标去倒推，而不是套一个放之四海皆准的模板。

4.3 容量与成本指标：性能不只是技术账，还是经济账

性能测试做到高阶，一定会碰到“成本指标”。我做的很多容量规划项目，最终落地问题不是“能不能扛住”，而是“用多少机器扛住”。单台机器的极限吞吐是多少、峰值流量下的资源消耗曲线长什么样，这些都是把技术指标转化为预算数字的依据。

成本类指标可以从以下角度提取：

• 每实例最大支撑TPS：一台应用服务器能跑到多少TPS，直接决定扩容倍数。
• 单事务资源消耗：一次完整事务平均消耗多少CPU毫秒、占用多少内存增量。
• 带宽消耗与费用：大文件下载、视频流场景尤其重要，数据量/秒往往比请求数/秒更能体现资源成本。
• 扩容边际收益：从1台扩到2台，TPS是否接近翻倍？如果只提升30%，说明系统存在其他瓶颈，盲目扩容是浪费钱。

这部分的输出对架构决策特别重要。性能测试报告里加一段“容量预估”：按峰值流量计算需要几台应用、几台DB、多大的带宽，领导做预算时就能直接抄作业。

4.4 拐点指标：从压力曲线里找系统的三个关键并发点

如果你做容量测试，最有价值的一张图不是我前面说的任何单一指标，而是“并发数-TPS-RT”三条曲线叠在一起的趋势图。通过曲线形态，可以清楚找到三个点：

• 最佳并发点：TPS随并发数同步上升，RT基本平稳。这个区间是系统最健康的工作区。
• 最大并发点：TPS达到峰值，不再随并发增加而上升，RT开始抬头。这是系统最大处理能力的临界点。
• 退化并发点：TPS反而下降，RT急剧恶化，错误率上升。系统已经过载，进入了“越压越垮”的阶段。

找到这三个点之后，容量规划的结论基本就成形了：日常运行要让负载落在最佳并发点附近，峰值流量可以短暂冲击到最大并发点附近，但绝不应该长期停留在退化区。很多线上事故之所以发生，就是负载长时间处于退化区，系统先响应缓慢，随后雪崩。性能测试里如果只看最高TPS，不看曲线拐点，相当于只知道一个人能跑多远，却不知道他从哪里开始会受伤。

5. 指标落地实操：从选定指标到采集，再到报警阈值

5.1 按测试类型选指标：不要一套模板走天下

我经常收到类似的测试计划，不管什么场景都列“RT、TPS、错误率、CPU”，这种做法错倒没错，但没有针对性。不同测试类型，指标重点完全不同：

选定指标的时候，我习惯先问自己一句：“这次测试要回答什么决策问题？”如果决策是“版本能不能上线”，核心看RT和错误率；如果决策是“线上要加几台机器”，核心看容量拐点和单实例TPS；如果决策是“某模块的缓存到底该不该加”，那就得看DB的慢查询和缓存命中率。指标是工具，不是目的，一切为决策服务。

5.2 JMeter里怎么盯指标：聚合报告、CSV日志和后端监听器

JMeter是目前最常见的压测工具，我就以它为例讲讲指标采集。聚合报告（Summary Report/聚合报告）里会直接给出Average、Median、90% Line、99% Line、Throughput、Error%等字段。很多人截图只截Average和Throughput，我把这种做法称为“自废武功”，因为最有价值的99% Line就摆在旁边。

更规范的做法是勾选“Save Responses to a file”或配置后端监听器，把原始样本数据落盘。压测结束后，用脚本对CSV日志做二次分析，可以算P999、超时率、响应时间分布，甚至做时间窗口切片。举一个CSV日志二次分析的简单思路：

• 把每个事务的响应时间按秒聚合，生成“每秒最大RT”曲线。
• 统计每小时内P99变化，判断是否存在劣化趋势。
• 按错误类型拆错误码，定位是超时、5xx还是断言失败。

命令行压测时，我用类似这样的参数：

jmeter -n -t script.jmx -l result.jtl -e -o report_dir

-e -o配合会生成HTML报告，里面自带各类指标图表，包括响应时间分布、TPS曲线、错误率等。但要注意，工具生成的报告只是原始数据可视化，不代表结论，结论永远需要你自己结合业务去下。

5.3 阈值不要拍脑袋：两条校准思路

性能测试里最常被问的问题是：“RT到底要小于多少才算合格？”我从来不直接给一个固定数，而是用两条思路校准：

第一，以线上历史数据为基准。如果线上日常P99是300ms，压测环境如果跑到800ms，那么不管绝对数值多漂亮，都是劣化。

第二，以用户可感知的体验目标为基准。对于电商接口，用户能明显感知的临界点大约在1秒到2秒；超过3秒基本会流失。你可以把目标定为“P95 < 1s，P99 < 2.5s”。注意这里的数字必须结合业务属性来定，不是照抄。查询类接口和下单类接口，用户耐心完全不一样。

阈值的另一种用途是报警。稳定性测试过程中，一旦某个指标超过阈值就自动通知，比如P99连续5分钟超过目标值。专业的做法是给指标设置“黄线”和“红线”：黄线代表性能劣化预警，红线代表已经不可接受。不要只设一个阈值，因为单点抖动太常见了，很容易误报。

5.4 报告里如何“讲指标”：三明治结构

性能测试报告不是数据堆砌，我总结的“三明治”结构可以直接套用：

• 第一层：结论。开门见山说“系统在XX并发下，满足/不满足XX目标”。
• 第二层：证据。用P99、TPS、错误率、资源利用率曲线支撑结论，图表要带上下界限。
• 第三层：归因与建议。如果没达标，定位瓶颈在哪一层，给出可执行的优化方向。

这里再强调一次：指标之间要对得上。如果你写“TPS达到2000”，那么RT必须是同一时段的数据，CPU、内存曲线也得能匹配上。很多人各截各的图、各取各的时段，结果就是报告里的数字互相打架——这种报告交上去，不仅是浪费，还会让整个测试团队的公信力受损。

6. 性能测试指标面试高频问题：不是背答案，而是会推导

6.1 TPS高，响应时间就一定低吗？

不一定。这两者受系统排队模型影响。在系统没有达到容量上限前，提高并发可以从一定程度上提高TPS，但RT通常也会上升，只是上升幅度平缓。当系统达到容量上限之后，TPS不再增长，RT继续上升，形成“TPS平台+RT陡增”的典型状态。所以面试时如果问“TPS高是不是性能好”，正确答案应该是：TPS高只能说明系统处理事务的速率高，必须结合RT和资源利用率一起判断。

6.2 平均响应时间为什么不能单独作为性能指标？

因为平均值会被极端值拉偏。我给一个直观的例子：100个请求中，99个耗时0.1秒，1个耗时5秒，平均值约为0.149秒，看起来很好，可是有1%的用户等了5秒。P99、P999、最大响应时间和超时率要一起看。这也是性能测试中用百分位数替代平均值的原因。

6.3 并发数、线程数、在线用户数是一回事吗？

完全不同。在线用户数只是“挂着”的人，不一定在发请求；线程数是压测脚本模拟的操作者数量，受思考时间和响应时间影响；真正意义上的系统并发数是“同时处理中的请求数”，可以用Little‘s Law估算：并发数 = TPS × 平均响应时间。面试时能写出这个公式并解释清楚，基本就说明你理解了并发模型的本质。

6.4 如何定位性能瓶颈？

我的回答永远是“分层定位”。先看业务指标，确定哪些请求慢、错误率如何；再看系统资源，CPU是否打满、内存是否持续增长、IO是否出现等待；然后看中间件，线程池是否占满、连接池是否耗尽、GC是否异常；最后回到代码层，慢SQL、锁竞争、超大对象序列化。性能问题极少只在一个点，但顺着链路逐层看，总能找到首要瓶颈。最忌讳的是看到CPU高就直接说“加机器”，高CPU背后的原因可能是死循环、GC线程占满，也可能是正常业务打满——先分清楚，再开药。

6.5 稳定性测试跑多久才够？

这是一个没有标准答案的问题，但判断逻辑是有的：至少覆盖一个完整的业务周期和定时任务周期。如果线上每小时有批处理任务，稳定性测试至少跑几小时；如果有日终任务，至少覆盖24小时。判断标准不是时间本身，而是趋势指标是否平稳。错误率有没有随时间上升？内存有没有单调上涨？P99有没有持续恶化？只要趋势不对，哪怕跑了72小时也不能说通过。

我在实际项目中见过太多“跑了24小时、错误率0、内存平稳、看起来全绿”但上线后仍然出问题的情况，原因往往是脚本太温和，根本没产生足够压力。稳定性测试的负载设计必须让系统保持在一个合理的压力水位上，比如峰值的70%到80%，否则你测的只是“空闲态稳定性”，没什么参考价值。

最后说一点我在实操中最深的体会：性能测试的指标数量不是越多越好，关键是每一层指标都能为下一层判断提供依据。收到一个测试任务，别急着开压测脚本，先把“这次测试要回答什么问题”写下来，再倒推需要哪些指标、用什么工具采集、阈值定多少。这套流程熟练之后，你会发现收藏这篇文的意义不是背指标清单，而是拿到任何项目都能快速搭出一套能自洽、能说服人的指标体系。