第一章：性能分析基础
大家好，我是你们的老朋友。今天咱们聊聊性能分析这件事。
说实话，我见过太多团队把性能优化搞成了「玄学」。服务器一慢，大家就开始瞎猜：是不是数据库慢了？是不是代码写崩了？结果折腾半天，连问题在哪都没找到。
为什么会这样？说白了，就是缺少一套系统的方法论。今天这一章，我就带你把这个地基打牢。
1.1 性能指标定义
先问个问题：什么叫「性能好」？
你可能会说：「响应快呗。」嗯，没错，但不够全面。我习惯把性能指标分成三个维度来看：
| 维度 | 核心指标 | 通俗理解 |
|---|---|---|
| 响应时间 | RT、TP99、TP999 | 用户等多久才能看到结果 |
| 吞吐量 | QPS、TPS、RPS | 系统每秒能处理多少请求 |
| 资源利用率 | CPU、内存、IO、网络 | 服务器累不累，有没有瓶颈 |
我个人最看重的是 TP99。为什么？因为平均响应时间（Avg RT）太容易被「平均」骗了。举个例子：
# 假设有100个请求
# 99个请求耗时 10ms
# 1个请求耗时 10秒
# 平均RT = (99*10 + 10000) / 100 ≈ 109ms
# TP99 = 10ms（99%的请求都在10ms内完成）
你看，平均RT看起来还行，但那个倒霉的用户等了10秒。TP99能帮你抓住这些「尾部延迟」的问题。
避坑指南：我曾经接手过一个项目，监控面板上平均RT只有200ms，看起来一切正常。结果用户天天投诉卡顿。后来一查TP999，好家伙，2.3秒。这就是典型的「平均数陷阱」。
1.2 性能分析工具概览
工具这东西，贵精不贵多。我这些年用下来，真正好用的就这几样：
1.2.1 系统级工具
- top / htop：看CPU和内存，我每天上班第一件事就是敲一下
top - iostat：磁盘IO的照妖镜，IO高不高，一看便知
- vmstat：系统整体健康度，CPU、内存、IO一把抓
- netstat / ss：网络连接状态，排查连接数过多的问题
1.2.2 应用级工具
- cProfile：Python自带的性能分析器，轻量好用
- py-spy：采样式分析器，不需要改代码，生产环境也能用
- memory_profiler：逐行分析内存使用，找内存泄漏的神器
- line_profiler：逐行分析代码耗时，精准定位慢函数
1.2.3 链路追踪工具
- OpenTelemetry：现在最火的链路追踪标准，我建议新项目直接上这个
- Jaeger / Zipkin：分布式追踪的老牌选手
- SkyWalking：国产之光，对Java/Python支持都不错
我的习惯：先拿系统级工具扫一遍，确定瓶颈在CPU、内存还是IO。然后再用应用级工具深入代码层面。别一上来就搞cProfile，那是杀鸡用牛刀。
1.3 性能分析流程
好，工具都认识了。那具体怎么用？我总结了一套「四步法」：
- 发现问题：监控报警、用户投诉、压测不达标
- 定位瓶颈：用系统级工具缩小范围
- 深入分析：用应用级工具找到具体代码
- 优化验证：改完代码，重新压测，确认效果
听起来很简单对吧？但实际执行时，很多人会卡在第二步。
举个例子。有一次线上告警说接口响应变慢了。我第一反应不是看代码，而是先跑了个top：
$ top -p 12345
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12345 deploy 20 0 1.2g 456m 32m R 89.3 5.6 12:34.56 python
CPU 89.3%，嗯，问题在CPU上。接着我用py-spy采样了一下：
$ py-spy record -o profile.svg --pid 12345
生成的火焰图一看，好家伙，一个JSON序列化的函数占了60%的CPU时间。原来是有个地方在循环里反复调用json.dumps。
改完代码，再压测，响应时间从800ms降到了120ms。整个过程不到半小时。
注意：性能分析最忌讳「猜」。我曾经见过一个团队，觉得是数据库慢，花了两天优化SQL，结果发现瓶颈在Nginx的worker_connections配置上。所以，一定要用数据说话，别靠直觉。
1.4 本章小结
来，咱们捋一下今天的内容：
- 性能指标要看TP99，别被平均数骗了
- 工具分系统级和应用级，先用系统级缩小范围
- 分析流程是「发现→定位→分析→验证」，别跳步
下一章，咱们会深入聊聊CPU性能分析。到时候我会手把手教你用火焰图找CPU瓶颈，还会分享一个我踩过的坑——Python GIL到底怎么影响性能。
嗯，今天就到这儿。记住一句话：没有数据，就没有优化。