📚 课程目录第1章性能调优全景图

1. 性能调优全景图

大家好，我是老张。做了十几年系统性能工程，踩过的坑比写过的代码还多。今天咱们聊聊性能调优的全景图——说白了，就是搞清楚系统到底慢在哪，以及怎么用最小的代价把速度提上去。

你想想看，一个系统跑得慢，原因可能有一百种。但真正要命的，往往就那么一两个点。我管它们叫「瓶颈」。

系统瓶颈，就是整个系统里最拖后腿的那个环节。它像一根水管里最细的那段——不管你前面多粗，流量就卡在那。

核心定义：瓶颈是系统中限制整体吞吐量或响应时间的单一资源或组件。

我在项目中遇到过最典型的例子：一个电商平台的大促活动，数据库CPU才用到30%，但TPS就是上不去。查了半天，发现是连接池配得太小，线程全在等连接。你说CPU闲着有啥用？

常见的瓶颈类型，我列了个表：

我的经验：别一上来就怀疑代码。先看资源层——CPU、内存、IO、网络。80%的性能问题，资源层就能看出端倪。

这个问题我问过很多新人。他们的回答往往是：「出问题了再看日志呗。」

嗯，这个想法很危险。

我经历过一次惨痛的教训：一个支付系统，半夜两点突然变慢。等我早上看到告警，已经慢了好几个小时，积压了几十万笔交易。后来复盘发现，问题从出现到不可用，其实只有3分钟。如果当时有实时监控，我完全可以在3分钟内介入，而不是等到天亮。

实时监控的价值，说白了就三点：

我个人习惯，任何系统上线前，必须配好三套监控：

避坑指南：我曾经见过一个团队，监控指标配了200多个，但告警阈值设得乱七八糟。结果每天告警几百条，运维直接无视了。记住：监控不是越多越好，是要能帮你快速定位问题。

聊完概念，咱们上点硬货。性能调优有两个定律，我建议你刻在脑子里。

这个定律讲的是：系统加速比受限于你无法并行化的那部分。

公式很简单：

加速比 = 1 / ((1 - P) + P / N)

其中：

举个例子：一个任务，串行部分占10%，并行部分占90%。你用100个核去跑，加速比是多少？

加速比 = 1 / (0.1 + 0.9/100) = 1 / 0.109 ≈ 9.17

看到了吗？100个核，理论加速比才9倍。那10%的串行部分，就是你的瓶颈。

我的建议：调优前，先找到那个串行瓶颈。别一上来就加机器、加线程。我曾经见过一个团队，为了优化一个串行处理的日志模块，加了32台服务器——结果一点用没有。因为瓶颈根本不在那里。

这个法则更直观：

L = λ × W

其中：

你想想看，如果系统里同时有100个请求在处理，每个请求平均耗时200ms，那吞吐量就是：

λ = L / W = 100 / 0.2 = 500 TPS

这个公式告诉我们一个残酷的事实：响应时间越长，能支撑的并发就越低。

实战技巧：我在做容量评估时，经常用利特尔法则反推。比如目标吞吐量是1000 TPS，响应时间要求200ms，那系统需要支撑的并发数就是：L = 1000 × 0.2 = 200。如果连接池只有100，那肯定扛不住。

说了这么多，咱们画张图把整个知识体系串起来。这是我做性能调优时脑子里始终挂着的一张图：

这张图是我多年调优经验的浓缩。你看，从瓶颈出发，分三条线：定位、分析、调优。最后汇聚到三个黄金法则上。

记住：性能调优不是玄学，是有方法论可循的。Amdahl定律告诉你该优化哪，利特尔法则告诉你优化到什么程度。剩下的，就是动手干。

咱们这一章，把性能调优的底子打好了：