半夜两点，线上数据库CPU被打满，值班同学把压测报告甩到群里说：“平均响应时间200毫秒，TPS有800，怎么一上线就卡死？”
我看了看报告，又看了看监控面板，回了一句：“你压测的时候，P99是多少？错误率是多少？连接池被打到什么水位了？”
对方沉默了一会儿，答不上来。
这个场景我遇到过太多次。性能测试指标这五个字，看起来谁都会写，实际上大多数人都停留在“平均响应时间 + TPS + 错误率”这三件套上。三个数字填进报告，看着像模像样，但既说不清楚系统真正的容量边界，也解释不了线上为什么会出问题。
这篇文章不是教科书式的指标清单罗列。我会把性能测试指标的底层逻辑、计算方式和真实项目里的使用经验一次性讲透，包括不同技术栈（普通接口、数据库、对象存储、AI推理模型）分别该盯哪些指标，JMeter、LoadRunner、Prometheus这些工具链怎么配合才能把指标看明白，以及我在实际项目中因为指标理解偏差踩过的几个坑。不管你是刚入行的测试工程师、后端开发，还是做SRE/运维的同学，这篇都值得存下来慢慢看。
1. 从“指标焦虑”到指标体系：性能测试到底在看什么
我注意到一个现象：网上搜“指标”两个字，跳出来的大半是各种神秘公式和源码，搞得很多人产生了“指标焦虑”——好像拿到一套别人验证过的指标公式，就能量化一切问题。
性能测试指标不是玄学，它是一把有刻度的尺子。尺子本身不解决任何问题，但没有了它，你连系统当前处于什么状态都说不清楚。
要建立指标体系，先要搞清楚一件事：你压测一次系统，本质上是在回答三类问题——
- 用户端感受如何？一个请求从发出去到拿到结果，到底花了多久？有没有失败？会不会超时？
- 系统当前在做什么？单位时间内处理了多少请求？同时有多少请求在处理中？吞吐量是上升还是下跌？
- 系统是靠什么支撑的？CPU、内存、磁盘、网络、连接池，这些资源还有多少余量？哪个会先顶不住？
第一类问题对应的是响应时间、错误率、成功率，这些是用户直接感知的指标；第二类对应的是TPS、QPS、并发数，这些是系统对外表现的指标；第三类对应的是CPU使用率、内存占用、磁盘IO、网络带宽、连接池水位、GC停顿时间，这些是底层资源和饱和度指标。
1.1 三层指标体系
很多初学者搞混指标，就是因为把三层混在一起看。
打个比方：开车的时候，响应时间是“你踩下油门到车速变化的感觉”，吞吐量是“一小时跑了多少公里”，资源利用率是“发动机转速和温度”。如果你只盯着转速表，发现转速很高，能得出“这车有问题”的结论，但你说不出来驾驶体验具体差在哪。反过来，如果你只盯着车速，车速下来了就抱怨车不行，但没看到其实前面是上坡，油门已经踩到底了。
性能测试指标也一样。响应时间慢了，可能不是应用代码的问题，而是底层资源已经耗尽；TPS上不去，可能不是并发开得不够，而是一个数据库连接池被某条慢SQL占光了。
这就是为什么要分层建立指标体系。我每次做压测，至少会建三层监控视图：
| 层次 | 代表指标 | 回答的问题 |
|---|---|---|
| 用户可感知层 | 平均响应时间、P95/P99、错误率、超时率 | 用户体感好不好 |
| 系统行为层 | TPS/QPS、并发数、吞吐量 | 系统处理能力够不够 |
| 资源与饱和度层 | CPU、内存、磁盘IO、网络、连接池、GC | 还有多少余量，瓶颈在哪 |
1.2 指标不是越多越好：先回答“要回答什么问题”
另一个常见误区是“全都要监控”。动不动就上百个指标，最后真正看的人还是只盯平均值那一个数字。
我的经验是：根据压测目标决定指标范围。你这次压测是想验证容量规划，还是定位性能瓶颈？是想对比两个版本之间的性能差异，还是验证上线后的稳定性？
- 做容量验证：盯TPS、P99、错误率、CPU、连接池水位。
- 做瓶颈定位：盯响应时间曲线、GC日志、慢SQL、线程池活跃线程数、磁盘await。
- 做稳定性测试：盯错误率、内存泄漏趋势（RSS持续上升）、Full GC频率、句柄数。
指标不是越多越好，而是“足够回答核心问题”就好。后面我会按照不同场景展开，告诉你具体该盯哪几个数字。
2. 核心指标逐个拆解：定义、计算方式和它们之间的关系
这节是基础中的基础，但请仔细看，因为很多有几年工作经验的人，在“平均值”这个问题上依然会犯错。
2.1 响应时间：平均值和分位数，别被平均骗了
响应时间指从客户端发出请求到收到完整响应所花的时间，通常包含网络传输、排队等待、应用处理三个部分。
性能测试报告里最常见的指标是平均响应时间。但我要说一句可能颠覆你认知的话：平均值是最不值得信任的性能指标。
举个例子。假设有10个请求，响应时间分别是：100ms、110ms、90ms、105ms、95ms、100ms、108ms、92ms、103ms、3000ms。
平均一下，算出来是390ms左右，看起来“还行”。但这10个请求里有1个花了3秒，这个3秒的用户体验是灾难级的。如果你的系统重点是抢购、支付这类高并发场景，那一个3秒的请求可能意味着用户流失，甚至是超时重试带来的连锁失败。
正确做法是看分位数，尤其是P95和P99。P99代表“99%的请求都小于这个值”，剩下那1%的长尾请求才最能反映用户端真实体验。我自己的习惯是：
- P50（中位数）：反映系统正常状态下的典型表现。
- P95：反映一般性波动下的体验。
- P99：反映极端情况，是排查隐患的关键。
- 最大值：一般只做参考，不参与结论判断，因为最大值经常被一次GC、一次网络抖动带偏。
压测报告里如果只有平均值，那这份报告的参考价值要打五折。无论是JMeter的聚合报告还是LoadRunner的Analysis，都可以看到分位数数据，一定要把这些数字写进结论。
2.2 吞吐量与并发数：TPS、QPS和并发之间到底是什么关系
吞吐量是衡量系统处理能力的核心指标。有两个接近的概念：TPS（每秒事务数）和QPS（每秒查询数）。
很多人分不清这两个词。简单说：QPS更偏向“每秒钟能处理多少个请求”，TPS更强调“每秒钟能完成多少个完整业务事务”。比如一次登录实际上发出了3个请求（获取验证码、提交登录、获取用户信息），那QPS是3，TPS可能是1。做接口压测时两个概念都能用，但要统一口径，别混着说。
真正容易搞混淆的是并发数。并发数在压测工具里，是指工具同时发出的请求数量，比如JMeter线程数设为100，那就是模拟100个并发请求。但在真实系统里，“在线用户数”和“并发请求数”是两个完全不同的概念——1万个在线用户，同一时刻真正在点按钮、发请求的可能只有几百个。
所以压测时不要问“我系统支持多少用户在线”，而要问“同时有多少请求在途处理中”。这正是Little‘s Law要回答的问题。
2.3 错误率与资源利用率：最容易失真也最容易被忽略的两类指标
错误率是硬指标。HTTP层面要区分4xx和5xx，4xx一般是参数、权限问题，和性能无关；5xx才是系统处理能力不足的信号。业务层面还要注意：HTTP状态码200，不代表业务成功。很多系统在响应体里返回{"code":500}，但HTTP状态码依然是200。压测脚本里如果没做断言，这种业务错误会被全部吞掉，错误率显示是0%，完美得令人害怕。
资源利用率方面，我最常看的几个数：
- CPU：us（用户态）、sy（内核态）、wa（IO等待）。wa飙高说明磁盘IO在拖后腿。
- 内存：RSS、page cache、swap使用量。持续攀升不回落，大概率是内存泄漏。
- 磁盘IO：IOPS、await（平均IO等待时间）、使用率。await超过20ms就要警惕。
- 网络：带宽、丢包率、TCP重传率。压测机的网卡经常被人忽略。
2.4 让指标互联：Little‘s Law与吞吐-响应时间曲线
单个指标只能反映系统的一个侧面，指标和指标之间的联动关系才真正值钱。
Little’s Law是一个非常实用的公式，在排队论和性能工程里都成立：
系统中的平均请求数（L）= 吞吐量（λ） × 平均响应时间（W）
举个例子。一个接口平均响应时间是200ms，每秒钟处理500个请求，那系统里同时“在飞”的请求数大约是 500 × 0.2 = 100 个。如果这个服务背后的数据库连接池只有50个连接，那必然有50个请求在排队等连接，响应时间会被急剧拉长。
这就是我常说的“指标之间会打架”。当你发现TPS上不去、响应时间却直线上升时，多半不是吞吐量计算错了，而是某个资源池（线程池、连接池、队列）已经满了，系统在排队。
另一个必看的曲线是吞吐-响应时间曲线。随着并发数从低到高，吞吐量会经历“线性上升—增长放缓—触顶回落”三个阶段，响应时间则在拐点之后急剧恶化。我每次压测完，都会把这两条曲线叠在一起看，找那个“拐点”——那就是系统真实的容量上限。
3. 不同技术栈的指标选型：接口、数据库、对象存储和AI推理
同样是“性能测试”，不同技术栈的关注点差别非常大。通用指标只是底座，具体到这个场景，你得知道哪些指标才能判断系统是否健康。
3.1 Web接口/微服务场景
这是最常见的压测场景。除了基础的响应时间、TPS、错误率外，微服务场景下我还会额外盯：
- 线程池活跃线程数：Spring Boot的Tomcat线程池默认200，如果活跃线程长期接近上限，说明线程不够用，要么扩容，要么优化业务耗时。
- 连接池水位：包括数据库连接池、Redis连接池、HTTP Client连接池。连接池耗尽时，表现往往不是资源飙升，而是接口RT突然出现大量毛刺。
- GC停顿时间：JVM的Full GC停顿几百毫秒，对P99的影响是毁灭性的。压测时一定要开GC日志，或者用Prometheus采集GC指标。
- 服务间调用链路：如果压测的是A服务，但A会同步调用B、C、D，那B、C、D的RT和错误率也得监控。否则你会发现A的响应时间上去了，但找遍A自己的日志都查不到原因。
3.2 数据库场景
数据库往往是整个压测过程中第一个暴露瓶颈的地方。DBA视角和测试视角看的东西不完全一样，我作为测试人员最关注这几个：
- 慢查询数：压测过程中慢查询数量的变化趋势，比单看平均查询耗时更敏感。
- 连接数：连接数曲线是否接近max_connections上限。连接数打满时，新的请求会被拒之门外，应用端的表现就是“连接超时”。
- 锁等待：压测并发上去之后，如果出现大量锁等待，说明表结构或者事务隔离级别有问题。
- Buffer Pool命中率：命中率下降说明数据没有进内存，磁盘IO会成为下一个瓶颈。
这里有一个很反直觉的经验：数据库连接池耗尽时，数据库本身的CPU可能并不高。因为连接都堵在排队，真正在执行的SQL并不多。只看数据库CPU会得出“数据库很健康”的错误结论，必须结合应用端的连接池监控一起看。
3.3 对象存储/中间件场景：MinIO v2与v3指标差异
如果被测系统依赖对象存储（比如MinIO）或其他中间件，你需要额外采集这些组件的指标。
以MinIO为例，很多人在压测时直接把Prometheus面板导入，发现数据为空或者口径不对，原因往往是指标版本不匹配。MinIO的监控指标经历了一次从v2到v3的演进：
- v2指标：暴露路径和管理粒度比较粗，一部分指标需要靠label（bucket、api_name）来区分维度，写PromQL时要用一堆正则匹配，维护成本高，而且部分指标在Grafana面板上容易统计失真。
- v3指标：在较新的版本中指标体系被重新结构化，命名空间更规范，S3 API请求、磁盘IO、节点状态等维度的指标分组更清晰，查询语句的可读性也好很多。代价是：基于v2写的Grafana panel升级后基本要重写查询语句。
这块给所有人的建议是：做压测前，先确认中间件版本对应的监控指标版本。否则你采集到的“磁盘饱和度”“请求延迟”可能是过时口径的指标，得出来的性能结论根本不成立。具体到MinIO v3的指标命名和采集端点，以你部署版本的官方文档为准，因为这类组件迭代很快，容易踩版本坑。
3.4 AI推理场景：YOLO模型的精度指标与性能指标要分开看
这两年AI模型相关的性能压测需求越来越多，热词里常有“yolo模型指标说明”这类问题。我的第一句话永远是：模型评估指标和性能测试指标，是两个维度的事情，别混为一谈。
拿YOLO这类目标检测模型举例：
- 精度指标：mAP、Precision、Recall。这些是模型准不准的问题，属于模型质量评估范畴，和性能压测无关。
- 性能指标：单帧推理延迟（ms/frame）、FPS、批处理吞吐、GPU利用率、显存占用、推理服务接口的P99延迟。
同样是YOLO模型，部署在边缘设备和云端GPU集群上的性能指标侧重点完全不同。边缘端你要盯的是单帧延迟能不能压到实时视频流的帧间隔以内；云端批量推理你更关心的则是吞吐和显存能不能压满、每张卡的资源成本高不高。
压测AI推理服务时还有个容易翻车的地方：数据预处理和结果后处理往往占掉大量时间。我压测过一个OCR服务，模型推理只占40%的时间，图片解码和文字后处理却占了60%。如果只盯着模型推理延迟，你会得出“系统性能很好”的错误结论，实际整个服务的P99早已超标。
4. 指标采集与分析工具链：JMeter、LoadRunner与可观测体系怎么配合
指标本身不会自动出现在你面前，你得用工具去采集、计算、可视化。这里讲几个主流工具的用法和它们各自擅长的地方。
4.1 JMeter：从聚合报告里正确读出指标
JMeter是目前最常用的开源压测工具。跑完压测后，大家都会打开聚合报告（Aggregate Report），但很多人的读法有问题。
聚合报告里关键列是：样本数、平均值、中位数、90%行、异常%、吞吐量、接收/发送KB/s。我一般这样读：
- 平均值只做参考，重点看90%行和异常%。如果90%行远超平均值，说明数据分布不均衡，存在长尾。
- 吞吐量单位可以切换为“s/sec”，这才是每秒钟的请求数。很多人默认是按照分钟或小时显示的，导致TPS算错。
- 异常%只统计了HTTP层面的错误，业务错误要靠断言。建议给每个Sampler加上响应断言，把业务失败也打进结果。
JMeter只负责生成流量和记录结果，系统资源指标需要额外监控。我习惯用ServerAgent + PerfMon插件采集本机CPU、内存、磁盘IO，如果压测环境已经接了Prometheus，也可以直接在Grafana上看，不需要额外部署。
4.2 LoadRunner：事务、集合点与曲线分析
LoadRunner是商业性能测试工具，很多传统金融、制造企业还在用。它和JMeter最大的不同在于分析和场景控制能力更强。
LoadRunner里三个核心概念：
- 事务（Transaction）：用
lr_start_transaction和lr_end_transaction包住一段业务操作，比如“下单”，统计的是完整业务事务的耗时，而不是单个请求。这一点比JMeter默认按Sampler统计更贴近实际业务。 - 集合点（Rendezvous）：用于让多个虚拟用户在某一时刻同时提交请求，模拟真实的“并发提交”场景，比如秒杀、抢票。如果没有集合点，Vuser随着脚本执行天然错峰，并发度其实没那么高。
- Analysis的曲线图：重点看Running Vusers和Hits per Second、Transaction Response Time这三个图的联动。Vuser持续增加，但Hits per Second不再上升，说明系统已经到吞吐上限；Transaction Response Time在同一时刻开始爬坡，这就是拐点。
在结果解读层面，LoadRunner和JMeter本质是相通的：不要看平均，要看分位；不要只看工具端的数字，要和服务端资源趋势图对应起来。
4.3 Prometheus+Grafana：压测过程的可观测性建设
现在做性能测试，不管用什么压测工具，我都推荐在目标环境里搭一套Prometheus + Grafana的监控，纯粹为了压测期间的可观测性。
Prometheus采集指标的口径和压测工具完全不同。压测工具记录的是“请求端视角”，Prometheus记录的是“服务端视角”。两个视角一起看，才能定位问题在网络层还是应用层。常用PromQL我列几个：
- QPS：
rate(http_requests_total[1m]) - P95延迟：
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[1m])) by (le)) - CPU使用率：
100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[1m])) * 100)
Grafana上建议把压测工具的吞吐指标和服务的CPU、RT曲线放到同一个时间轴上。这样一旦TPS掉头，你能立刻看到同一时刻是CPU打满了还是GC发生了，定位效率能提升一个量级。
4.4 工具选型对比
| 工具 | 适合场景 | 指标特点 | 主要局限 |
|---|---|---|---|
| JMeter | 开源生态、接口压测、自定义脚本 | 数据粒度细，可扩展插件 | Web页面交互无法真实模拟 |
| LoadRunner | 企业级、复杂协议（ERP/数据库） | 事务分析精准，场景控制强 | 授权成本高，学习曲线陡 |
| Grafana k6 | 现代DevOps、K8s环境 | 代码化压测，CI友好 | 复杂事务脚本开发成本高 |
| 自研压测平台 | 大规模分布式压测 | 指标统一、报告自动化 | 需要额外开发维护成本 |
工具没有绝对的好坏，选你能驾驭、团队能维护的那个就行。关键是采集到的指标口径要一致，别今天用JMeter算TPS，明天用LoadRunner算TPS，两边的数值对不上，排查问题就是灾难。
5. 阈值不是拍脑袋：SLA拆解、排队论与容量基线
“响应时间小于200ms”“CPU使用率不要超过70%”，这些阈值在网上随处可见，但很少有人告诉你它们是怎么推导出来的。实际上，合理的阈值来自两个途径：业务目标反推，以及排队论对系统行为的约束。
5.1 从业务目标反推出技术指标
性能指标不能脱离业务目标存在。举一个我最近做的电商下单接口例子：
业务方给出的目标是：大促峰值2万QPS，下单接口TP99要小于1秒，失败率低于0.1%。
从这个目标出发，我要做的是把它拆成技术指标：
- 这个接口内部会调用库存服务、订单服务、支付服务，链路里最耗时的坏点决定TP99能否达标。所以我要给每个下游服务设置更严格的子目标，比如每个下游内部调用TP99低于200ms。
- 2万QPS的外呼流量，对应用服务器的线程池、数据库连接池、消息队列都会产生压力。结合Little’s Law，假设TP99是1秒，那系统内平均在途请求就是 20000 × 1 = 20000 个，这决定了服务实例数和连接池大小根本不是拍脑袋定的。
- 失败率0.1%意味着10万次请求里最多允许100次失败，超时重试、熔断策略的触发阈值都必须围绕这个数来设计。
SLA拆解的核心是：每个技术指标都能追溯到一条业务价值。凡是说不清楚“为什么定这个数”的阈值，都是不合格的。
5.2 为什么CPU推荐水位是70%-80%：一个排队论视角
很多文章告诉你“CPU使用率不要超过80%”，但不解释为什么。这里补上推导逻辑，理解了它，你以后定阈值心里就有底了。
用最简单的M/M/1排队模型做近似：系统利用率ρ（比如CPU使用率）越高，请求排队的概率越大。平均排队时间大致是 服务时间 × ρ/(1-ρ)（这里做了简化，忽略一些高阶项，但直观意义完全正确）。
- 当ρ=0.5时，排队时间是服务时间的 0.5/0.5 = 1 倍，即每个请求平均等一个服务时间。
- 当ρ=0.8时，排队时间是服务时间的 0.8/0.2 = 4 倍。
- 当ρ=0.9时，排队时间是服务时间的 0.9/0.1 = 9 倍。
看到没有，CPU利用率从80%到90%，利用率的绝对值只增加了10%，但排队时间从4倍暴涨到9倍。这就是为什么业界普遍推荐CPU水位控制在70%-80%。不是这条线好看，而是超过这条线之后，系统的响应时间会以非线性方式急剧恶化。
同样的逻辑适用于所有“资源池”类指标：连接池使用率、线程池活跃度、磁盘利用率。安全水位通常在70%-80%，超过这个词意味着你在为排队买单。
5.3 建立自己的性能基线与容量拐点
阈值不能永远停留在纸面上。一个靠谱的做法是：通过压测建立系统自己的性能基线，并标出容量拐点。
具体操作分三步：
- 选定一个有代表性的业务场景，比如“登录”或“下单”，固定压测脚本和测试数据。
- 以不同并发数（比如10、50、100、200、500）逐步加压，每次运行5-10分钟，记录TPS、RT、错误率、资源利用率。
- 把TPS和资源利用率画成曲线，找到“TPS不再跟随并发数增长”的点，这就是容量拐点；将拐点附近的并发数乘以0.7-0.8，就是建议的安全并发水位。
这套数据积累起来之后，每次发版都能对比：这次发布后TPS是提升了还是下降了，P99有没有恶化。性能回归测算起来就有据可依，而不是每次上线前临时抓瞎。
6. 我在真实项目里踩过的五个指标坑
最后一个部分，聊点实战中真实的教训。这些坑我基本都踩过，写出来你引以为戒。
6.1 平均值陷阱：P99爆炸，平均还很好看
有一年我压测一个订单查询接口，聚合报告显示平均响应时间80ms，TPS 1200，看起来非常漂亮。但我顺手看了一眼P99：2.1秒。
这个接口确实有慢查询问题，但慢查询只影响少量请求，平均值完全看不出来。后来排查发现，系统每隔一段时间就会触发一次Full GC，停顿500ms以上，直接导致那一小段窗口内的请求全部被拖到2秒开外。
从那次以后，我所有的压测报告，第一行永远是TP99，第二行才是平均值。平均值可以用于整体概况描述，但任何性能结论都必须以分位数为主。
6.2 预热不足：前几分钟的压测数据根本不能信
JVM应用启动后，热点代码需要经过JIT编译优化才能达到最佳性能；连接池在启动初期也处于“还没填满”的状态。如果你压测一上来就直接计时，前几分钟的数据通常会比真实水平差很多。
有一次我压测一个Spring Boot服务，前3分钟TPS只有400，后面慢慢爬到了900。如果只跑5分钟就把前3分钟的数据也统计进去，结论直接腰斩。
现在我的压测习惯是：正式压测前，先跑一个5-10分钟的“预热流量”，把JIT、连接池、缓存全部热起来，然后重置统计，再开始正式记录。这一个小操作，能让报告数字准确很多。
6.3 压测机先挂了：工具本身也是性能瓶颈
有次压测一个纯静态文件服务，TPS从500开始一直上不去，服务端CPU不到20%，我一度以为问题在服务端的网络配置。查了半天发现，压测机自己的CPU已经打满100%了。
压测工具（尤其是JMeter这种单机模式）在高并发下本身会消耗大量CPU和内存。如果压测机先成为瓶颈，你压的就不是目标系统，而是压测机自己。解决方法是：分布式压测，或者直接用云上的压测集群，确保压测机资源冗余足够。
6.4 缓存命中虚高：结果好看，上线打回原形
这个坑最容易出现在压测数据设计上。如果你压测时反复请求同一个接口、同一批数据，Redis缓存会被全部命中，数据库几乎零压力，报告里RT和TPS都好看得惊人。
真实流量下，用户请求的数据千奇百怪，缓存命中率根本不可能有这么高。结果压测报告写着“支持5000 QPS”，上线当天数据库就被打爆。
正确做法是压测数据要随机化、规模化。测试数据量至少是线上真实数据量的2-3倍，并且要模拟一部分缓存不命中的场景，这样压测结果才对得上真实容量。
6.5 只盯系统资源，忘了业务成功指标
这是我最想强调的一点：系统指标正常，不代表业务是成功的。
有一次压测登录接口，服务端CPU、内存、RT全部正常，TPS也符合预期。但压测脚本里的断言我没有检查，后来才发现，有一段时间接口返回的都是同一个业务错误码——验证码校验失败。因为HTTP状态码是200，错误率统计成了0%，所有系统指标都“正常”，但真实业务成功率只有不到50%。
从那以后，我的压测脚本里，每个关键接口都会加一个响应断言，把业务成功与否打进结果统计。性能指标和业务指标必须放在一起看：TPS再高、RT再低，业务成功率垮了，这个压测就是失败的。
做了这么多年性能测试，我越来越觉得，指标不是用来交差和炫技的，它是你和系统之间的一门共同语言。别急着搭一堆炫目的仪表盘，也别到处找什么“万能指标公式”。先把你业务的P99、TPS、CPU、GC这几项核心指标测清楚，用真实流量验证过，再慢慢扩展监控范围。
最后分享一个小习惯：我每次压测完，第一件事不是打开汇总表格，而是把响应时间曲线和资源利用率曲线叠在一张时间轴图上，看看拐点出现在哪一秒，那个时刻发生了什么。这个习惯帮我发现了不知道多少个隐藏问题。你的压测报告里也应该有这样的“故事”，而不仅仅是一堆冰冷的数字。
