性能剖析

何时使用

• 用户说"这个接口好慢""页面卡""内存一直涨";
• 上线后性能变差,需要定位是哪个改动引起的;
• 优化前想先知道瓶颈在哪,不想瞎猜;
• 需要量化"优化到底有没有用"。

使用步骤

第 1 步:明确现象与目标

1. 慢在哪里:接口、页面、构建、启动,还是内存;
2. 现状指标:能不能给出数字(响应时间、CPU、内存);
3. 目标:优化到什么程度算达标。

第 2 步:建立可复现基线

• 固定环境、固定请求、固定数据量;
• 跑 3-5 次取中位数,记录基线数字;
• 没有基线,优化前后就没法对比,不算完成。

第 3 步:取证定位

工具选择、指标含义、profiler 读法见 references/TOOLS_METRICS.md。

按场景选工具:

定位时看三个层次:

1. 时间花在哪(接口 → 函数 → 具体行);
2. 瓶颈类型:CPU 密集、IO 等待、锁等待、还是网络;
3. 是否和调用次数相关(N+1、循环内查询、重复计算)。

第 4 步:提出并实施优化

常见方向:

• 数据库:N+1 改批量查询、加索引(配合 EXPLAIN 验证)、缓存热点数据;
• 代码:循环外提计算、减少重复对象创建、并行化独立任务;
• 前端:懒加载、防抖、减少重渲染;
• 架构:缓存、异步、限流(最后考虑)。

一次只改一个点,改完立即重跑基线。

第 5 步:输出报告

# 性能剖析报告

## 基线
环境、请求、优化前指标

## 瓶颈
位置、证据(profiler 截图/日志)、原因

## 优化
改动点、为什么有效

## 结果
优化后指标、提升百分比

输入与输出

• 输入:性能问题描述 + 可运行的环境;
• 输出:基线数据 + 瓶颈证据 + 优化结果。

示例

现象: 列表接口 2 秒,预期 <500ms。

取证: 慢日志显示同一条用户查询执行了 100 次(每行一次)。

根因: ORM 循环内逐行查询,典型 N+1。

优化: 改成一次批量查询,内存里做关联。

结果: 接口降到 120ms,提升 94%。

辅助脚本

scripts/benchmark.py 测量接口 p50/p95/p99 与成功率,建立可复现基线:

python scripts/benchmark.py <URL> [请求数] [并发]

示例服务见 examples/slow-api。

注意事项

• 不猜:每个结论都要有 profiler、日志或基线数据支撑;
• 先量化再优化:没有基线的"优化"无法验收;
• 一次改一个变量,改多个就说不清是谁起的作用;
• 数据库优化先 EXPLAIN 再动索引,别凭感觉加;
• 优化要保住正确性,改完跑一遍原有测试。

不适用场景

• 用户只想要"感觉快了"的主观判断(要求量化);
• 没有可运行环境,只有代码片段;
• 问题是资源不足(加机器能解决),不属于代码优化。

验证方式

1. 触发:"这个接口好慢""帮我查性能";
2. 检查:报告含基线、瓶颈证据、优化前后数字;
3. 复核:按报告步骤重跑,结果可复现。