3. 性能指标定义：响应时间、吞吐量、并发用户数、错误率、资源利用率
聊性能测试，绕不开的就是这几个核心指标。我见过不少团队，工具跑得飞起，报告出一大堆，结果一问「你的响应时间达标了吗？」——答不上来。说白了，指标定义不清，后面的分析全是空中楼阁。
今天咱们就把这五个指标掰开揉碎了讲。每个我都会结合项目里的真实场景，告诉你它们到底怎么用、坑在哪。
3.1 响应时间：用户感知的第一道门
响应时间，就是从用户发出请求到收到完整响应所花的时间。你想想看，点一个按钮，转圈转了三秒，你什么感觉？我反正会直接关掉页面。
但这里有个细节：响应时间不是单一数值。它通常包含：
- 网络传输时间：数据在客户端和服务端之间跑的时间
- 服务端处理时间：应用服务器、数据库处理请求的时间
- 客户端渲染时间：浏览器或App解析、渲染的时间
我个人习惯把响应时间拆成「前端耗时」和「后端耗时」来看。有一次我在项目中排查一个慢接口，前端说后端慢，后端说前端慢，吵了半天。后来我把两端时间分别打出来，发现80%的时间花在了数据库查询上——嗯，问题一下就清楚了。
关键点：响应时间要关注百分位值（如P90、P99），而不是平均值。平均值会被极端值拉偏，P99能告诉你最差的1%用户经历了什么。
我的经验：对于Web系统，我一般建议P99响应时间不超过2秒。如果是API接口，P99控制在500ms以内比较合理。
3.2 吞吐量：系统能扛多少活
吞吐量，单位时间内系统能处理的请求数量。常见单位有TPS（每秒事务数）和QPS（每秒查询数）。
吞吐量和响应时间其实是「跷跷板」关系。响应时间短了，吞吐量自然就上去了。但反过来，吞吐量压到极限时，响应时间往往会急剧恶化——这就是所谓的「拐点」。
我记得有一次做双十一压测，系统在2000 TPS时响应时间只有200ms，一切正常。但当我压到2500 TPS时，响应时间突然飙到3秒，数据库连接池直接打满。这就是典型的吞吐量拐点。
| 指标 | 说明 | 常见参考值 |
|---|---|---|
| TPS | 每秒完成的事务数（含完整业务逻辑） | 电商下单：500-2000 TPS |
| QPS | 每秒查询数（通常指读请求） | 搜索引擎：5000-50000 QPS |
| HPS | 每秒点击次数（Web页面请求） | 门户网站：1000-10000 HPS |
注意：不要只看峰值吞吐量。要结合响应时间一起看，否则你测出来的「高吞吐」可能是用户已经卡到崩溃的假象。
3.3 并发用户数：别被这个数字骗了
并发用户数，很多人理解成「同时在线的人数」。其实不对。真正的并发用户数，是同一时刻正在向系统发起请求的用户数。
举个例子：一个网站有10万在线用户，但大部分人在浏览页面、填写表单，真正在「发请求」的可能只有1000人。这1000人才是并发用户数。
我曾经遇到一个项目，产品经理说「我们要支持10万并发」，我一听就笑了。后来仔细一问，他说的其实是注册用户数。嗯，这种误会太常见了。
并发用户数和吞吐量、响应时间的关系可以用一个公式表达：
并发用户数 = 吞吐量 × 平均响应时间这个公式叫Little's Law，是排队论里的经典结论。你想想看，如果平均响应时间是1秒，每秒能处理100个请求，那系统里同时存在的请求数就是100个——这就是并发用户数。
避坑指南：我曾经在压测时把并发用户数设得特别高，结果系统直接挂了。后来发现，并发用户数要逐步递增，找到系统的「最大稳定并发」——也就是响应时间不恶化时的最大并发数。
3.4 错误率：系统健康的晴雨表
错误率，就是失败请求占总请求的比例。常见的错误类型有：
- HTTP 5xx：服务端错误，比如500、502、503
- 超时错误：请求在规定时间内没得到响应
- 业务错误：比如下单时库存不足、支付失败
我一般把错误率分成两个维度看：
- 系统级错误率：HTTP 5xx、连接超时等，这类错误通常意味着系统有瓶颈
- 业务级错误率：比如下单失败、登录失败，这类错误可能不是系统问题，而是业务逻辑问题
有一次压测，我发现错误率突然从0.1%飙到5%。查了半天，发现是数据库连接池满了，新请求拿不到连接直接超时。这就是系统级错误。而业务级错误，比如用户输入了错误的验证码，那就不算系统问题。
建议标准：对于核心业务，错误率应控制在0.1%以下。非核心业务可以放宽到1%。超过5%的错误率，基本可以判定系统存在严重问题。
3.5 资源利用率：CPU、内存、IO
资源利用率，说白了就是系统「累不累」。CPU、内存、磁盘IO、网络IO，这四个是重点。
CPU利用率
CPU忙的时间占总时间的比例。我一般关注两个点：
- 用户态CPU：应用代码在跑
- 系统态CPU：内核在干活，比如IO操作、锁竞争
如果系统态CPU占比过高，说明系统在频繁做上下文切换或者IO操作——这通常是个坏信号。
内存利用率
内存用了多少，还剩多少。但光看总量不够，还要看：
- 堆内存使用：Java应用重点关注GC频率和堆大小
- Swap使用：如果系统开始用Swap，性能会急剧下降
我记得有一次排查内存泄漏，发现应用的内存占用一直在涨，GC也回收不掉。最后定位到一个静态Map，不断往里塞数据，从不清理——嗯，经典的内存泄漏案例。
磁盘IO
磁盘读写速度。重点关注：
- IOPS：每秒读写次数
- 吞吐量：每秒读写的数据量
- IO等待时间：进程等待IO完成的时间
如果IO等待时间持续偏高，说明磁盘是瓶颈。这时候可以考虑换SSD，或者优化SQL减少磁盘访问。
我的经验：CPU利用率建议控制在70%以下，内存利用率80%以下，磁盘IO等待时间不超过10ms。超过这些值，系统就可能进入不稳定状态。
3.6 知识体系总览
下面这张图，把五个指标的关系画清楚了。你可以看到，响应时间和吞吐量是核心，并发用户数是输入，错误率和资源利用率是输出——它们共同决定了系统的性能表现。
这五个指标，每一个单独拎出来都能讲半天。但在实际项目中，我更建议你把它们当成一个整体来看。比如，响应时间长了，可能是CPU满了，也可能是磁盘IO慢了——你得综合判断。
好了，这一章的内容就到这。记住，指标定义清楚，后面的分析才有意义。别像我以前那样，跑了一堆数据，最后发现连「什么是响应时间」都没统一——那才叫白忙活。
一句话总结：响应时间看P99，吞吐量看拐点，并发用户数看真实请求，错误率看类型，资源利用率看瓶颈。五个指标一起看，才能看清系统的真实面貌。