application-performance-performance-optimization

使用专业的性能与优化 Agent，端到端优化应用性能：

[延伸思考：该工作流编排了一个覆盖整个应用栈的全面性能优化过程。从深度剖析与基线建立开始，工作流逐步推进到各系统层中的针对性优化，通过负载测试验证改进效果，并建立持续监控以保持性能。每个阶段都基于前几个阶段的洞察，形成数据驱动的优化策略，解决真实瓶颈而非理论上的改进。该工作流强调现代可观测性实践、以用户为中心的性能指标以及高性价比的优化策略。]

何时使用此技能

• 协调后端、前端和基础设施的性能优化
• 建立基线并通过剖析识别瓶颈
• 设计负载测试、性能预算或容量规划
• 为性能和可靠性目标构建可观测性

何时不要使用此技能

• 任务只是小范围的局部修复，没有更广泛的性能目标
• 无法访问指标、追踪或剖析数据
• 请求与性能或可扩展性无关

说明

1. 确认性能目标、约束和目标指标。
2. 通过剖析、追踪和真实用户数据建立基线。
3. 在整个技术栈中执行分阶段优化，并确保可衡量的影响。
4. 验证改进效果并设置护栏以防止回归。

安全

• 未经批准和未设置保护措施时，避免对生产环境进行负载测试。
• 逐步推出性能变更，并制定回滚计划。

阶段 1：性能剖析与基线

1. 全面的性能剖析

• 使用 Task 工具，subagent_type="performance-engineer"
• 提示词："针对以下内容全面剖析应用性能：$ARGUMENTS。生成 CPU 使用率的火焰图、用于内存分析的堆转储、追踪 I/O 操作，并识别热点路径。如可用，使用 DataDog 或 New Relic 等 APM 工具。包括数据库查询剖析、API 响应时间和前端渲染指标。为所有关键用户旅程建立性能基线。"
• 上下文：初始性能调查
• 输出：包含火焰图、内存分析、瓶颈识别和基线指标的详细性能剖析

2. 可观测性栈评估

• 使用 Task 工具，subagent_type="observability-engineer"
• 提示词："评估以下内容的当前可观测性设置：$ARGUMENTS。审查现有监控、使用 OpenTelemetry 的分布式追踪、日志聚合和指标收集。识别可见性缺口、缺失指标以及需要更好埋点的领域。推荐 APM 工具集成以及面向业务关键操作的自定义指标。"
• 上下文：来自步骤 1 的性能剖析
• 输出：可观测性评估报告、埋点缺口、监控建议

3. 用户体验分析

• 使用 Task 工具，subagent_type="performance-engineer"
• 提示词："分析以下内容的用户体验指标：$ARGUMENTS。测量 Core Web Vitals（LCP、FID、CLS）、页面加载时间、可交互时间和感知性能。如可用，使用真实用户监控（RUM）数据。识别性能较差的用户旅程及其业务影响。"
• 上下文：来自步骤 1 的性能基线
• 输出：UX 性能报告、Core Web Vitals 分析、用户影响评估

阶段 2：数据库与后端优化

4. 数据库性能优化

• 使用 Task 工具，subagent_type="database-cloud-optimization::database-optimizer"
• Prompt："针对以下内容优化数据库性能：$ARGUMENTS，基于性能分析数据：{context_from_phase_1}。分析慢查询日志，创建缺失的索引，优化执行计划，使用 Redis/Memcached 实现查询结果缓存。审查连接池、预编译语句和批处理机会。如有需要，考虑只读副本和数据库分片。"
• 上下文：来自第 1 阶段的性能瓶颈
• 输出：优化后的查询、新索引、缓存策略、连接池配置

5. 后端代码与 API 优化

• 使用 Task 工具，subagent_type="backend-development::backend-architect"
• Prompt："针对以下内容优化后端服务：$ARGUMENTS，聚焦瓶颈：{context_from_phase_1}。实现高效算法，添加应用层缓存，优化 N+1 查询，有效使用 async/await 模式。实现分页、响应压缩、GraphQL 查询优化和批量 API 操作。添加熔断器和舱壁以提升弹性。"
• 上下文：来自第 4 步的数据库优化、来自第 1 阶段的性能分析数据
• 输出：优化后的后端代码、缓存实现、API 改进、弹性模式

6. 微服务与分布式系统优化

• 使用 Task 工具，subagent_type="performance-engineer"
• Prompt："针对以下内容优化分布式系统性能：$ARGUMENTS。分析服务间通信，实现服务网格优化，优化消息队列性能（Kafka/RabbitMQ），减少网络跳数。实现分布式缓存策略并优化序列化/反序列化。"
• 上下文：来自第 5 步的后端优化
• 输出：服务通信改进、消息队列优化、分布式缓存配置

第 3 阶段：前端与 CDN 优化

7. 前端打包与加载优化

• 使用 Task 工具，subagent_type="frontend-developer"
• Prompt："针对以下内容优化前端性能：$ARGUMENTS，聚焦 Core Web Vitals：{context_from_phase_1}。实现代码分割、tree shaking、懒加载和动态导入。使用 webpack/rollup 分析优化打包体积。实现资源提示（prefetch、preconnect、preload）。优化关键渲染路径并消除阻塞渲染的资源。"
• 上下文：来自第 1 阶段的 UX 分析、来自第 2 阶段的后端优化
• 输出：优化后的打包产物、懒加载实现、改进后的 Core Web Vitals

8. CDN 与边缘优化

• 使用 Task 工具，subagent_type="cloud-infrastructure::cloud-architect"
• Prompt："针对以下内容优化 CDN 和边缘性能：$ARGUMENTS。配置 CloudFlare/CloudFront 以实现最优缓存，为动态内容实现边缘函数，通过响应式图片和 WebP/AVIF 格式设置图片优化。配置 HTTP/2 和 HTTP/3，实现 Brotli 压缩。为全球用户设置地理分布。"
• 上下文：来自第 7 步的前端优化
• 输出：CDN 配置、边缘缓存规则、压缩配置、地理优化

9. 移动端与渐进式 Web 应用优化

• 使用 Task 工具，subagent_type="frontend-mobile-development::mobile-developer"
• Prompt："针对以下内容优化移动端体验：$ARGUMENTS。实现 Service Worker 以支持离线功能，通过自适应加载针对慢速网络进行优化。减少移动端 CPU 的 JavaScript 执行时间。为长列表实现虚拟滚动。优化触摸响应性和动画流畅度。如适用，考虑 React Native/Flutter 特定优化。"
• 上下文：来自第 7-8 步的前端优化
• 输出：移动端优化代码、PWA 实现、离线功能

第 4 阶段：负载测试与验证

10. 全面负载测试

• 使用 Task 工具，设置 subagent_type="performance-engineer"
• 提示词："使用 k6/Gatling/Artillery，对以下内容进行全面负载测试：$ARGUMENTS。根据生产流量模式设计符合实际情况的负载场景。测试正常负载、峰值负载和压力场景。如适用，涵盖 API 测试、基于浏览器的测试和 WebSocket 测试。在不同负载级别测量响应时间、吞吐量、错误率和资源利用率。"
• 上下文：阶段 1-3 中的所有优化
• 输出：负载测试结果、负载下的性能、性能瓶颈、可扩展性分析

11. 性能回归测试

• 使用 Task 工具，设置 subagent_type="performance-testing-review::test-automator"
• 提示词："为以下内容创建自动化性能回归测试：$ARGUMENTS。为关键指标设置性能预算，使用 GitHub Actions 或类似工具将测试集成到 CI/CD 流水线。为前端创建 Lighthouse CI 测试，使用 Artillery 进行 API 性能测试，并创建数据库性能基准测试。为性能回归实现自动回滚触发器。"
• 上下文：第 10 步的负载测试结果、阶段 1 的基线指标
• 输出：性能测试套件、CI/CD 集成、回归预防系统

阶段 5：监控与持续优化

12. 生产监控设置

• 使用 Task 工具，设置 subagent_type="observability-engineer"
• 提示词："为以下内容实施生产性能监控：$ARGUMENTS。使用 DataDog/New Relic/Dynatrace 设置 APM，使用 OpenTelemetry 配置分布式追踪，并实施自定义业务指标。为关键指标创建 Grafana 仪表板，设置 PagerDuty 性能下降告警。为关键服务定义 SLI/SLO 和错误预算。"
• 上下文：所有先前阶段的性能改进
• 输出：监控仪表板、告警规则、SLI/SLO 定义、运行手册

13. 持续性能优化

• 使用 Task 工具，设置 subagent_type="performance-engineer"
• 提示词："为以下内容建立持续优化流程：$ARGUMENTS。创建性能预算跟踪机制，为性能变更实施 A/B 测试，并在生产环境中设置持续性能分析。记录待处理的优化机会，创建容量规划模型，并建立定期性能评审周期。"
• 上下文：第 12 步的监控设置，以及之前的所有优化工作
• 输出：性能预算跟踪、待处理的优化机会、容量规划、评审流程

配置选项

• performance_focus："latency" | "throughput" | "cost" | "balanced"（默认："balanced"）
• optimization_depth："quick-wins" | "comprehensive" | "enterprise"（默认："comprehensive"）
• tools_available：["datadog", "newrelic", "prometheus", "grafana", "k6", "gatling"]
• budget_constraints：设置基础设施变更可接受的最高成本
• user_impact_tolerance："zero-downtime" | "maintenance-window" | "gradual-rollout"

成功标准

• 响应时间：关键端点的 P50 < 200ms、P95 < 1s、P99 < 2s
• 核心 Web 指标：LCP < 2.5s、FID < 100ms、CLS < 0.1
• 吞吐量：支持当前峰值负载的 2 倍，且错误率 <1%
• 数据库性能：查询 P95 < 100ms，且没有查询耗时超过 1s
• 资源利用率：正常负载下 CPU < 70%、内存 < 80%
• 成本效益：每美元带来的性能至少提升 30%
• 监控覆盖率：100% 的关键路径均已埋点并配置告警

性能优化目标：$ARGUMENTS