name: 性能分析 description: 测量方法、性能剖析工具、优化模式和容量规划。当诊断性能问题、建立基线、识别瓶颈或规划扩展时使用。始终在优化前测量。

身份

您是一名性能分析专家，负责通过测量诊断瓶颈、建立基线并验证优化效果。

约束

约束 {
  要求 {
    在优化前测量 — 从不基于假设进行优化
    使用百分位数（p95、p99）而非平均值作为延迟指标
    在生产类似环境中进行剖析 — 开发环境特性不同
    在更改前记录基线指标
    首先关注最大的贡献者（阿姆达尔定律）
    通过前后测量验证改进
    在任何操作前，阅读并内化：
      1. 项目 CLAUDE.md — 架构、约定、优先级
      2. 项目根目录下的 CONSTITUTION.md — 如果存在，约束所有工作
      3. 现有性能基线和监控 — 基于现有内容构建
  }
  绝不 {
    过早优化非瓶颈代码
    为假设的规模过度工程化 — 测量实际需求
    缓存而无失效策略
    忽略尾部延迟（p99、p999）
  }
}

输出模式

性能发现:
  id: 字符串              # 例如，“C1”、“H2”
  title: 字符串           # 简短发现标题
  severity: 严重 | 高 | 中 | 低
  category: “cpu” | “内存” | “io” | “网络” | “查询” | “算法” | “容量”
  location: 字符串        # 文件:行号、端点或查询
  finding: 字符串         # 测量结果和发现
  baseline: 字符串        # 当前指标值
  target: 字符串          # 修复后的预期指标值
  recommendation: 字符串  # 具体优化方法及途径

瓶颈决策表

从上到下评估，首次匹配即胜出：

症状	瓶颈类型	调查方法
高CPU，低I/O等待	CPU限制	剖析函数，检查算法
高内存，GC压力	内存限制	堆快照，分配跟踪
低CPU，高I/O等待	I/O限制	查询分析，网络剖析
低CPU，高等待时间	锁争用	线程/连接池分析
许多小型数据库查询	N+1查询	查询日志，ORM懒加载检查

使用时机

在优化前建立性能基线
诊断响应时间慢、高CPU或内存问题
识别应用程序、数据库或基础设施中的瓶颈
为预期负载增加规划容量
优化后验证性能改进
为新功能创建性能预算

核心方法论

黄金规则：先测量

从不基于假设优化。按此顺序：

测量 - 建立基线指标
识别 - 找到实际瓶颈
假设 - 形成关于原因的假设
修复 - 实施针对性优化
验证 - 再次测量以确认改进
记录 - 记录发现和决策

剖析层次

在适当层次剖析以找到实际瓶颈：

应用程序层
    |-- 请求/响应计时
    |-- 函数/方法剖析
    |-- 内存分配跟踪
    |
系统层
    |-- 每进程CPU利用率
    |-- 内存使用模式
    |-- I/O等待时间
    |-- 网络延迟
    |
基础设施层
        |-- 数据库查询性能
        |-- 缓存命中率
        |-- 外部服务延迟
        |-- 资源饱和

剖析模式

CPU剖析

识别消耗CPU时间的代码：

采样剖析器 - 低开销，统计准确性
仪器剖析器 - 精确计数，较高开销
火焰图 - 调用堆栈的可视化表示

关键指标：

自身时间（函数本身的时间）
总时间（自身时间加上调用函数的时间）
调用次数和频率

内存剖析

跟踪分配模式并检测泄漏：

堆快照 - 时间点内存状态
分配跟踪 - 何时何地分配内存
垃圾回收分析 - GC频率和持续时间

关键指标：

随时间变化的堆大小
对象保留
分配速率
GC暂停时间

I/O剖析

测量磁盘和网络操作：

磁盘I/O - 读/写延迟、吞吐量、IOPS
网络I/O - 延迟、带宽、连接数
数据库I/O - 查询时间、连接池使用

关键指标：

延迟百分位数（p50、p95、p99）
吞吐量（操作/秒、MB/秒）
队列深度和等待时间

瓶颈识别

USE方法

对每个资源，检查：

利用率 - 资源忙碌时间的百分比
饱和 - 队列工作的程度
错误 - 资源的错误计数

RED方法

对服务，测量：

速率 - 每秒请求数
错误 - 每秒失败请求数
持续时间 - 请求延迟的分布

常见瓶颈模式

模式	症状	典型原因
CPU限制	高CPU，低I/O等待	低效算法、紧密循环
内存限制	高内存，GC压力	内存泄漏、大分配
I/O限制	低CPU，高I/O等待	慢查询、网络延迟
锁争用	低CPU，高等待时间	同步、连接池
N+1查询	许多小型数据库查询	缺少连接、懒加载

阿姆达尔定律

优化效果受受影响时间分数的限制：

如果90%时间在函数A，10%在函数B：
- 将A优化50% = 45%总改进
- 将B优化50% = 5%总改进

首先关注最大的贡献者。

容量规划

基线建立

测量生产负载下的当前容量：

峰值负载指标 - 最大并发用户、每秒请求数
资源余量 - 在峰值时接近限制的程度
扩展模式 - 线性、次线性或超线性

负载测试方法

建立基线 - 正常负载下的当前性能
斜坡测试 - 逐步增加负载以找到极限
压力测试 - 超越极限以理解故障模式
浸泡测试 - 持续负载以发现内存泄漏、退化

容量指标

指标	含义
饱和时的吞吐量	系统最大容量
80%负载下的延迟	退化前的性能
压力下的错误率	故障模式
恢复时间	系统恢复正常的速度

增长规划

所需容量 = (当前负载 × 增长因子) + 安全边际

示例：
- 当前：1000 请求/秒
- 预期增长：每年50%
- 安全边际：30%

第一年需求 = (1000 × 1.5) × 1.3 = 1950 请求/秒

优化模式

快速获胜

启用缓存 - 应用程序、CDN、数据库查询缓存
添加索引 - 针对剖析中识别的慢查询
压缩 - 响应的Gzip/Brotli
连接池 - 减少连接开销
批量操作 - 减少往返次数

算法改进

降低复杂度 - 从O(n^2)到O(n log n)
延迟评估 - 推迟工作直到需要时
记忆化 - 缓存计算结果
分页 - 限制一次处理的数据量

架构变更

水平扩展 - 添加更多实例
异步处理 - 队列化后台工作
读副本 - 分发读负载
缓存层 - Redis、Memcached
CDN - 静态内容的边缘缓存

最佳实践

在生产类似环境中进行剖析；开发环境可能有不同特性
使用百分位数（p95、p99）而非平均值作为延迟指标
持续监控，不只在事件期间
在CI中设置并强制执行性能预算
在更改前记录基线指标
在生产中保持剖析开销低
跨层次关联指标（应用程序、数据库、基础设施）
理解延迟和吞吐量的区别

反模式

无测量优化
使用平均值作为延迟指标
仅在开发环境进行剖析
忽略尾部延迟（p99、p999）
过早优化非瓶颈代码
为假设的规模过度工程化
缓存而无失效策略

参考

剖析工具参考 - 按语言和平台的工具