specsfy-specialist-performance-engineering

性能工程

何时使用

• 当有人报告响应缓慢、吞吐量低、资源使用过多、包体积过大，或不确定系统能否承受预期峰值时，使用此项。
• 也可用于审查已提出的优化方案，并确认它是否有测量过的基线和明确假设，还是仅凭直觉。
• 不用于设计生产环境中的指标／告警系统本身——这类工作请使用 $specsfy-specialist-observability；这里的重点是诊断并解决已经观察到或怀疑存在的具体性能问题。
• 当瓶颈在查询／索引时，与 $specsfy-specialist-postgres 配合；当修复需要在流水线中加入自动防护措施时，与 $specsfy-specialist-delivery-engineering 配合。

流程

1. 在改动任何代码之前，明确用户旅程、指标、目标百分位、预期负载和性能预算。
2. 使用有代表性的环境和数据量复现问题——绝不能基于微小的开发数据集进行诊断。
3. 测量当前基线，并按边界（客户端、网络、应用、数据库、外部依赖）分解耗时，以确定时间花在了哪里。
4. 提出具体假设，并针对已识别的边界使用合适的性能分析器／跟踪工具，而不是泛泛猜测优化方向。
5. 每次只改动一个相关因素，并在与基线相同的条件下重新测量。
6. 测试修复在真实负载、超时和重试情况下是否仍能保证正确性——无法在并发情况下正常工作的优化，就不算优化。
7. 创建防护措施（性能回归测试、流水线中的预算），避免性能回归再次悄然发生。

模式

• 使用百分位数（p50、p95、p99）和完整分布，绝不能只看平均值——平均值会掩盖对实际体验影响最大的长尾。
• 在决定优化方向之前，明确区分客户端、网络、应用、数据库和外部依赖的延迟。
• 同时测量冷缓存和热缓存，以及真实并发条件下的表现，而不只是单个请求。
• 在证明无缓存路径的成本并确定失效策略之前，不要添加缓存层——未经验证就添加缓存，是过时数据错误最常见的来源。
• 在负载、超时和重试情况下保持正确性：降低平均延迟但引入竞争条件或丢失重试的优化不可接受。
• 控制观察者效应（性能分析器／检测工具本身改变测量结果），并确保在测量 JIT、磁盘缓存或连接池之前完成预热。
• 根据预期的真实峰值场景确定容量和余量，而不是根据今天观察到的平均流量。

反模式

• 没有测量基线，只凭“感觉很慢”就开始优化：没有变更前后的数据，就无法判断改动是有帮助、没有效果，还是让其他百分位的表现变差。
• 未识别瓶颈所在的实际边界，就添加索引、缓存或并行处理来解决表面症状：这可能只解决测试环境中测得的症状，在生产环境中却毫无改善；也可能只是把瓶颈转移到别处，并未降低感知延迟。
• 比较两个版本的平均值，而不是在相同负载下比较相同的百分位分布：平均值更好，可能掩盖了更差的 p99 长尾。
• 在排查 N+1 查询、可并行化的串行调用或可避免的网络往返之前，就扩充硬件／副本——Web 系统变慢最常见的原因是网络往返过多，而不是 CPU 不足。

验证

• 使用归档的基线进行可重复的基准测试（而不是只做非正式记录），以便未来比较。
• 根据分解步骤中的证据分析 CPU、内存、I/O 或查询，而不是为了“以防万一”使用通用分析器。
• 进行负载测试，明确成功标准（目标负载下的目标百分位），并设置安全限制，避免测试期间影响真实生产环境。
• 在流水线中自动进行回归测试，并根据指标的历史稳定性调整灵敏度——噪声较大的指标需要更大的容差，以免持续产生误报。
• 如果没有在相同条件下比较变更前后的基线，就不要声称某项变更“更快”；“感觉更快”不算证据。

相关技能

• $specsfy-specialist-astro 和 $specsfy-specialist-nextjs 会在测量定位瓶颈后，在框架层面应用性能预算并进行修复。
• $specsfy-specialist-debugging 会隔离负载下出现的功能缺陷，避免将其与优化机会混为一谈。
• $specsfy-specialist-software-architecture 会在限制容量的是边界而非局部实现时，处理结构性变更。
• $specsfy-specialist-web-api-design 会在吞吐量和延迟优化期间保留重试、分页和契约。
• $specsfy-specialist-observability 用于构建信号系统，在生产环境中的性能下降演变成事故之前将其检测出来。
• 当确认的瓶颈位于查询、索引或缓存策略时，使用 $specsfy-specialist-postgres 和 $specsfy-specialist-redis。
• $specsfy-specialist-delivery-engineering 用于将性能防护措施转变为流水线中的自动门禁。

请阅读 references/standards.md，了解 Web Vitals、基准测试方法、负载测试、性能分析和性能预算，以及官方来源。