应用程序性能优化
application-performance-performance-optimization
使用专业的性能与优化代理，对应用性能进行端到端优化：
[深度思考：此工作流编排了一个涵盖整个应用栈的全面性能优化流程。从深度分析和基准建立开始，逐步在每个系统层进行针对性优化，通过压力测试验证改进效果，并建立持续监控以维持性能。每个阶段都基于前一阶段的洞察，构建一套数据驱动的优化策略，旨在解决实际瓶颈而非理论上的改进。该工作流强调现代可观测性实践、以用户为中心的性能指标以及高性价比的优化策略。]
适用场景
- 协调后端、前端及基础设施的性能优化
- 建立基准并进行分析以识别瓶颈
- 设计压力测试、性能预算或容量规划
- 为性能和可靠性目标构建可观测性
不适用场景
- 任务仅为局部的小修复，且没有更广泛的性能目标
- 无法获取指标、链路追踪（Tracing）或分析（Profiling）数据
- 请求与性能或可扩展性无关
执行指令
1. 确认性能目标、约束条件和目标指标。
2. 通过分析、链路追踪和真实用户数据建立基准。
3. 在全栈范围内执行分阶段优化，并确保影响可衡量。
4. 验证改进效果并设置防护栏以防止性能回退。
安全注意事项
- 未经批准和缺乏防护措施前，避免在生产环境进行压力测试。
- 逐步发布性能变更，并制定回滚计划。
第一阶段：性能分析与基准建立
1. 全面性能分析
- 使用 Task 工具，设置 subagent_type="performance-engineer"
- 提示词："全面分析 $ARGUMENTS 的应用性能。生成 CPU 使用率的火焰图、内存分析的堆转储（Heap Dumps）、追踪 I/O 操作并识别热点路径。如果可用，请使用 DataDog 或 New Relic 等 APM 工具。分析内容应包括数据库查询分析、API 响应时间以及前端渲染指标。为所有关键用户路径建立性能基准。"
- 上下文：初始性能调查
- 输出：包含火焰图、内存分析、瓶颈识别和基准指标的详细性能分析报告
2. 可观测性栈评估
- 使用 Task 工具，设置 subagent_type="observability-engineer"
- 提示词："评估 $ARGUMENTS 当前的可观测性配置。审查现有的监控、基于 OpenTelemetry 的分布式链路追踪、日志聚合和指标收集。识别可见性缺失、缺失的指标以及需要加强埋点的领域。针对业务关键操作推荐 APM 工具集成和自定义指标。"
- 上下文：步骤 1 的性能分析结果
- 输出：可观测性评估报告、埋点缺失分析、监控建议
3. 用户体验分析
- 使用 Task 工具，设置 subagent_type="performance-engineer"
- 提示词："分析 $ARGUMENTS 的用户体验指标。测量核心 Web 指标（Core Web Vitals）"
- 上下文：步骤 1 的性能基准
- 输出：UX 性能报告、核心 Web 指标（Core Web Vitals）分析、用户影响评估
第二阶段：数据库与后端优化
4. 数据库性能优化
- 使用 Task 工具，设置 subagent_type="database-cloud-optimization::database-optimizer"
- 提示词："针对 $ARGUMENTS 优化数据库性能，参考分析数据：{context_from_phase_1}。分析慢查询日志，创建缺失的索引，优化执行计划，使用 Redis/Memcached 实现查询结果缓存。审查连接池、预处理语句（prepared statements）和批量处理机会。根据需要考虑读副本和数据库分片。"
- 上下文：第一阶段的性能瓶颈
- 输出：优化后的查询、新索引、缓存策略、连接池配置
5. 后端代码与 API 优化
- 使用 Task 工具，设置 subagent_type="backend-development::backend-architect"
- 提示词："针对 $ARGUMENTS 优化后端服务，解决瓶颈：{context_from_phase_1}。实现高效算法，添加应用级缓存，优化 N+1 查询，有效使用 async/await 模式。实现分页、响应压缩、GraphQL 查询优化和批量 API 操作。添加熔断器（circuit breakers）和隔板（bulkheads）以增强韧性。"
- 上下文：步骤 4 的数据库优化、第一阶段的分析数据
- 输出：优化后的后端代码、缓存实现、API 改进、韧性模式
6. 微服务与分布式系统优化
- 使用 Task 工具，设置 subagent_type="performance-engineer"
- 提示词："优化 $ARGUMENTS 的分布式系统性能。分析服务间通信，实施服务网格（service mesh）优化，优化消息队列性能（Kafka/RabbitMQ），减少网络跳数。实施分布式缓存策略并优化序列化/反序列化。"
- 上下文：步骤 5 的后端优化
- 输出：服务通信改进、消息队列优化、分布式缓存设置
第三阶段：前端与 CDN 优化
7. 前端 Bundle 与加载优化
- 使用 Task 工具，设置 subagent_type="frontend-developer"
- 提示词："针对 $ARGUMENTS 优化前端性能，目标是改善核心 Web 指标：{context_from_phase_1}。实现代码分割（code splitting）、Tree Shaking、懒加载和动态导入。通过 webpack/rollup 分析优化 Bundle 体积。实施资源提示（prefetch, preconnect, preload）。优化关键渲染路径并消除渲染阻塞资源。"
- 上下文：第一阶段的 UX 分析、第二阶段的后端优化
- 输出：优化后的 Bundle、懒加载实现、改善的核心 Web 指标
8. CDN 与边缘优化
- 使用 Task 工具，设置 subagent_type="cloud-infrastructure::cloud-architect"
- 提示词："优化 $ARGUMENTS 的 CDN 和边缘性能。配置 CloudFlare/CloudFront 以实现最佳缓存，为动态内容实施边缘函数，设置响应式图像和 WebP/AVIF 格式的图像优化。配置 HTTP/2 和 HTTP/3，实施 Brotli 压缩。为全球用户设置地理分布。"
- 上下文：步骤 7 的前端优化
- 输出：CDN 配置、边缘缓存规则、压缩设置、地理优化
9. 移动端与渐进式 Web 应用 (PWA) 优化
- 使用 Task 工具，设置
subagent_type="frontend-mobile-development::mobile-developer"
- 提示词："针对 $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 定义、运维手册 (Runbooks)
13. 持续性能优化
- 使用 Task 工具，设置
subagent_type="performance-engineer"
- 提示词："为 $ARGUMENTS 建立持续优化流程。创建性能预算追踪，为性能变更实施 A/B 测试，在生产环境中设置持续剖析 (Continuous Profiling)。记录优化机会待办列表，创建容量规划模型，并建立定期性能评审周期。"
- 上下文：步骤 12 的监控设置、之前所有的优化工作
- 输出：性能预算追踪、优化待办列表、容量规划、评审流程
配置选项
- performance_focus: "latency" (延迟) | "throughput" (吞吐量) | "cost" (成本) | "balanced" (均衡) (默认: "balanced")
- optimization_depth: "quick-wins" (快速见效) | "comprehensive" (全面) | "enterprise" (企业级) (默认: "comprehensive")
- tools_available: ["datadog", "newrelic", "prometheus", "grafana", "k6", "gatling"]
- budget_cons
- 成本限制：设定基础设施变更的最大可接受成本
- 用户影响容忍度： "zero-downtime"（零停机） | "maintenance-window"（维护窗口） | "gradual-rollout"（渐进式发布）
成功标准
- 响应时间：关键端点 P50 < 200ms, P95 < 1s, P99 < 2s
- 核心 Web 指标 (Core Web Vitals)：LCP < 2.5s, FID < 100ms, CLS < 0.1
- 吞吐量：支持 2 倍当前峰值负载，且错误率 < 1%
- 数据库性能：查询 P95 < 100ms，无查询时间 > 1s
- 资源利用率：正常负载下 CPU < 70%, 内存 < 80%
- 成本效益：单位成本性能提升至少 30%
- 监控覆盖率：100% 的关键路径均已部署监控并配置告警
性能优化目标：$ARGUMENTS
局限性
- 仅在任务明确符合上述范围时使用此技能。
- 不要将输出结果视为针对特定环境的验证、测试或专家评审的替代方案。
- 如果缺失必要输入、权限、安全边界或成功标准，请停止操作并请求澄清。
