性能指标与监控：让数据说话
做性能优化，最怕什么？
怕的是「我觉得系统慢了」，但说不出到底慢在哪。
我刚开始带团队那会儿，经常遇到这种情况：业务方说系统卡，开发说代码没问题，运维说服务器资源还够。三方各执一词，谁也说服不了谁。后来我学乖了——先看指标，再说话。
今天我们就聊聊性能优化的「度量衡」：响应时间、吞吐量、QPS、TPS、并发数、资源利用率。以及怎么用工具把它们抓出来。
响应时间：用户感知的「第一道坎」
响应时间，说白了就是用户点一下按钮，到看到结果花了多久。
我习惯把它拆成三段：
- 网络传输时间：数据在客户端和服务端之间跑个来回
- 服务处理时间：服务器真正干活的时间
- 排队等待时间：请求到了，但前面还有人在排队
你想想看，用户只关心总时长。但作为工程师，你得知道瓶颈在哪一段。
核心经验：响应时间不是越短越好，而是「稳定地短」。我见过一个系统，平均响应时间50ms，但偶尔飙到5秒。这种「抖动」比稳定在200ms更让用户崩溃。
我的习惯：监控响应时间时，别只看平均值。看P99、P95更有意义。P99表示99%的请求都在这个时间内完成，剩下的1%才是你需要关注的「尾巴」。
吞吐量与QPS/TPS：系统能扛多少活
吞吐量，就是单位时间内系统能处理多少请求。
QPS（Queries Per Second）和TPS（Transactions Per Second）是它的两个常见变种。QPS偏查询，TPS偏事务。但在实际项目中，很多人混着用，也没太大问题。
我记得有一次帮一个电商平台做压测，他们的QPS目标是5000。结果一跑，发现数据库连接池先爆了。嗯，这就是典型的「吞吐量瓶颈」——代码写得再快，数据库扛不住也是白搭。
| 指标 | 含义 | 典型场景 |
|---|---|---|
| QPS | 每秒查询数 | 搜索引擎、读多写少的系统 |
| TPS | 每秒事务数 | 支付系统、订单系统 |
| 吞吐量 | 单位时间处理总量 | 所有系统通用 |
避坑指南：我曾经犯过一个错——把QPS和并发数混为一谈。QPS是每秒能处理多少请求，并发数是同时有多少请求在处理。两者有关系，但不是一回事。高并发不一定高QPS，如果每个请求处理得慢，并发再高也没用。
并发数：系统同时能接多少活
并发数，就是系统同一时刻能处理多少个请求。
这里有个经典公式：并发数 = QPS × 平均响应时间。
举个例子：如果QPS是1000，平均响应时间是200ms，那并发数就是1000 × 0.2 = 200。也就是说，系统需要同时处理200个请求才能达到这个吞吐量。
我在项目中遇到过一个问题：并发数设置得太高，结果线程切换开销反而拖慢了系统。后来我把线程池大小调到一个合理的值，性能反而提升了。你想想看，有时候「少即是多」。
资源利用率：别让硬件闲着，也别让它累死
CPU、内存、磁盘IO、网络带宽——这些是系统的「体力活」。资源利用率就是看它们忙不忙。
- CPU：超过80%就要警惕了。我习惯看CPU的「空闲时间」和「等待IO时间」
- 内存：别只看总量，要看「可用内存」和「交换分区使用率」
- 磁盘IO：iowait高，说明磁盘是瓶颈
- 网络：带宽打满，再好的代码也传不出去
个人经验：有一次系统慢得离谱，CPU才30%，内存也够。查了半天，发现是磁盘IO在「排队」。一个日志写得太频繁，把磁盘IO打满了。关掉冗余日志，问题解决。嗯，有时候问题不在你想的地方。
常用监控工具：Prometheus + Grafana
指标有了，怎么抓？
我个人习惯用 Prometheus 做数据采集，Grafana 做可视化展示。这套组合拳在业界几乎是标配。
Prometheus 的工作方式很简单：它定期去「拉」你的服务暴露的指标数据。你只需要在代码里暴露一个 /metrics 端点，Prometheus 就会自动来取。
# 一个简单的 Prometheus 配置示例
global:
scrape_interval: 15s # 每15秒拉一次数据
scrape_configs:
- job_name: 'my-service'
static_configs:
- targets: ['localhost:8080']Grafana 则负责把数据画成图表。你可以建一个仪表盘，把响应时间、QPS、CPU使用率放在一起看。一眼就能发现哪个环节出了问题。
我的建议：别把指标堆太多。一个仪表盘放5-7个关键指标就够了。信息太多反而看不清。我见过有人一个仪表盘放了30多个图表，结果谁都不看——太乱了。
知识体系一览
下面这张图，是我梳理的性能指标与监控的核心逻辑。你可以把它当作一个「检查清单」：
这张图把六个核心指标和监控工具串在了一起。你从「响应时间」出发，顺着箭头走，就能理清整个性能监控的脉络。
好了，这一章的内容就到这里。记住一句话：没有数据，就没有优化。下次系统慢了，别猜，先看指标。
总结一下：响应时间看用户感受，QPS/TPS看系统能力，并发数看资源需求，资源利用率看硬件状态。用Prometheus抓数据，用Grafana看趋势。这套组合拳打好了，性能优化就成功了一半。
可可精品资料库