性能指标详解：响应时间、吞吐量、并发用户数、资源利用率、错误率
各位好，我是老张。做接口性能测试好些年，踩过不少坑。
今天咱们聊聊最基础也最关键的东西——性能指标。很多新手上来就盯着"TPS多少""响应时间多少"，其实没搞懂这几个指标背后的关系，发现问题也不知道根因在哪。
我见过一个团队，压测发现响应时间从50ms涨到2s，他们只调了数据库连接池大小，结果越调越慢……后来发现是并发数估算错了。嗯，指标没吃透，优化就抓瞎。
核心观点：性能指标不是孤立的数字。响应时间、吞吐量、并发用户数、资源利用率、错误率，这五个指标必须放在一起看，才能定位瓶颈。
一、响应时间
定义：从客户端发送请求到收到完整响应所花费的时间。单位通常用ms或s。
说白了，就是用户等得心不心焦。我习惯把响应时间拆成几段看：
- 网络传输时间：客户端到服务器往返，受带宽、延迟影响
- 处理时间：服务器接收请求后，业务逻辑、数据库查询、外部调用等耗时
- 排队时间：请求在队列中等待被处理的时间。高并发时这个占比会飙升
我的经验：不要只看平均响应时间。P99（99%请求的响应时间）更能反映真实体验。有一次我排查线上问题，平均时间50ms，但P99到了1.2s——原来有个慢SQL每几百次触发一次，平均被拉平了。
衡量方法：
- 压测工具直接记录（如JMeter的聚合报告、wrk的延迟分布）
- APM工具（SkyWalking、Pinpoint）对每个接口打点，计算毫秒级别耗时
- 注意区分首次字节时间（TTFB）和完整加载时间
二、吞吐量
吞吐量衡量系统单位时间内能处理多少请求。常见单位：
| 指标名称 | 全称 | 含义 |
|---|---|---|
| TPS | Transactions Per Second | 每秒完成的事务数（一个事务可能包含多个请求） |
| QPS | Queries Per Second | 每秒完成的查询/请求数，常用于查询类接口 |
| RPS | Requests Per Second | 每秒请求数，更通用的说法 |
你想想看，响应时间和吞吐量其实是跷跷板关系。响应时间越短，单位时间内能处理的请求数就越多。但别搞反了——我见过有人调大了连接池，吞吐量没变，反而因为资源争抢导致响应时间变长。
注意：吞吐量有上限。当并发达到一定值后，吞吐量会趋于稳定甚至下降。那个拐点就是系统瓶颈的临界值。
三、并发用户数
定义：同一时刻对系统发起请求的用户数量。注意是"同时发送请求"，不是总注册用户数。
这里有个经典陷阱：很多人直接拿"日活用户"×系数来估算并发，结果压测时系统直接崩了。我曾经接手一个项目，运营说"最多2000人同时用"，我按照2000并发压测，数据库连接池爆了……后来仔细看日志，峰值时实际并发不到200。
衡量方法：
- 线上：通过日志、APM统计活跃会话数（如Tomcat的active threads）
- 压测：逐步增加虚拟用户数，同时观察响应时间和错误率的变化
核心公式（Little's Law）：并发用户数 = 吞吐量 × 平均响应时间。这个公式在系统稳定状态下成立。举个例子：如果TPS=100，平均响应时间=200ms（0.2s），那么并发数≈20。如果你想支撑1000并发，要么把吞吐量做到5000，要么把响应时间降到0.1s，或者两者都调。
四、资源利用率
资源利用率告诉你硬件被用到了什么程度。主要看这四个：
- CPU：用户态+系统态+等待I/O。注意区分CPU饱和（队列等待）和高负载但未饱和
- 内存：使用率、交换分区使用、GC频率（Java应用）
- 磁盘I/O：读写速率、I/O等待时间、队列深度
- 网络：带宽使用率、丢包率、TCP重传率
我个人习惯用top、vmstat、iostat这些命令行工具，配合监控面板（Prometheus+Grafana）看趋势。注意一点：CPU利用率达到70%左右就要警惕了，很多应用在70%之后响应时间会非线性增长。如果CPU已经100%但响应时间还能接受？别高兴太早——那说明你的CPU正在拼命排队，随时可能崩溃。
避坑指南：我曾经遇到一个案例，CPU利用率只有30%，但响应时间很高。排查发现是磁盘I/O wait超过40%——磁盘是瓶颈。别只看CPU，资源利用率要组合着看。
五、错误率
定义：错误请求数占总请求数的比例。通常用百分比表示。
错误率是性能问题的"报警器"。正常情况错误率应该接近0%（允许少量网络抖动）。一旦错误率开始爬升，就说明系统正在承受压力，某个环节崩了。
- HTTP 5xx：服务端错误，可能是连接超时、线程池满、数据库连不上了
- HTTP 4xx：客户端错误，但高并发时也可能因为限流、鉴权失败返回403/429
- 超时错误：请求没有在规定时间内返回，往往出现在慢查询或资源争抢
衡量方法：
- 压测工具直接统计错误率（JMeter的Error%）
- 线上通过网关日志、业务监控统计异常比例
- 注意区分"业务错误"（如参数校验失败）和"系统错误"（如500、503）
注意点：错误率不是越低越好。有时候系统为了降低错误率，大量请求在队列里排队，导致响应时间飙升——用户体验反而更差。错误率和响应时间要一起看。
五个指标怎么看？
好了，五个指标都讲完了。你可能会问：这么多指标，我到底关注哪个？
- 压测初期：看响应时间和错误率。如果响应时间正常但错误率高，优先排查服务端代码或配置。
- 压测中期：逐步增加并发数，同时看吞吐量。吞吐量不再增长时，记录此时的并发数和资源利用率。
- 压测后期：看资源利用率和错误率。如果CPU/IO还没打满但响应时间已经恶化，说明有锁、队列或外部依赖瓶颈。
我习惯列一张"性能基线表"，把每个接口在不同并发下的五个指标都记下来。一旦线上出现问题，拿实际指标和基线对比，定位很快。
| 接口 | 并发数 | 平均响应时间 | P99响应时间 | TPS | CPU% | 内存% | 错误率 |
|---|---|---|---|---|---|---|---|
| /api/order/create | 100 | 85ms | 210ms | 1050 | 45% | 32% | 0.01% |
| /api/order/create | 500 | 320ms | 1.8s | 1350 | 78% | 55% | 2.3% |
| /api/order/query | 200 | 42ms | 95ms | 4200 | 22% | 18% | 0% |
看上面这张表，/api/order/create在并发500时，P99响应时间飙到1.8s，错误率也到2.3%。但CPU才78%——说明瓶颈不在CPU，大概率在数据库锁或外部RPC。后续排查就能有的放矢。
总结一句话：搞懂这五个指标，你就能听懂系统在说什么了。别只看一个数，要看它们之间的关系。下一轮实战中，我们会用这些指标去诊断一个真实的接口瓶颈。