Files

163 lines
10 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
name: application-performance-performance-optimization
description: "通过性能分析、可观测性以及前后端调优,优化端到端应用性能。在需要协调全栈性能优化时使用。"
risk: unknown
source: community
date_added: "2026-02-27"
---
使用专门的性能与优化智能体,端到端地优化应用性能:
[扩展思考:该工作流在整个应用技术栈上编排了一个全面的性能优化流程。从深入性能分析与基线建立开始,工作流依次推进到每个系统层的定向优化,通过负载测试验证改进效果,并建立持续监控以维持性能。每个阶段都建立在前一阶段洞察的基础之上,形成一套数据驱动的优化策略,解决真实的瓶颈问题而非理论改进。工作流强调现代可观测性实践、以用户为中心的性能指标以及高性价比的优化策略。]
## 使用此技能的时机
- 协调后端、前端和基础设施层面的性能优化
- 建立基线并进行分析,以识别瓶颈
- 设计负载测试、性能预算或容量规划
- 为性能和可靠性目标构建可观测性
## 请勿使用此技能的时机
- 任务只是小型局部修复,没有更广泛的性能目标
- 无法获取指标、链路追踪或性能分析数据
- 请求与性能或可扩展性无关
## 操作说明
1. 确认性能目标、约束条件和目标指标。
2. 通过性能分析、链路追踪和真实用户数据建立基线。
3. 跨技术栈分阶段执行优化,确保每次优化都有可衡量的效果。
4. 验证改进效果,并设置防护措施以防止性能回退。
## 安全注意事项
- 未经审批和防护措施,请勿对生产环境进行负载测试。
- 逐步推广性能变更,并准备好回滚方案。
## 第一阶段:性能分析与基线建立
### 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" 的用户体验指标。测量核心网页指标(LCP、FID、CLS)、页面加载时间、可交互时间以及感知性能。如果可用,使用真实用户监控(RUM)数据。识别性能较差的用户旅程及其业务影响。
- 上下文:来自步骤 1 的性能基线
- 输出:用户体验性能报告、核心网页指标分析、用户影响评估
## 第二阶段:数据库与后端优化
### 4. 数据库性能优化
- 使用 Task 工具,subagent_type="database-cloud-optimization::database-optimizer"
- 提示词:基于分析数据 {context_from_phase_1},优化 "$ARGUMENTS" 的数据库性能。分析慢查询日志,创建缺失的索引,优化执行计划,使用 Redis/Memcached 实现查询结果缓存。审查连接池、预编译语句和批量处理机会。必要时考虑只读副本和数据库分片。
- 上下文:来自第一阶段的性能瓶颈
- 输出:优化后的查询、新索引、缓存策略、连接池配置
### 5. 后端代码与 API 优化
- 使用 Task 工具,subagent_type="backend-development::backend-architect"
- 提示词:针对瓶颈 {context_from_phase_1},优化 "$ARGUMENTS" 的后端服务。实现高效的算法,添加应用层缓存,优化 N+1 查询,有效使用 async/await 模式。实现分页、响应压缩、GraphQL 查询优化和批量 API 操作。添加断路器与隔离舱壁以提高弹性。
- 上下文:来自步骤 4 的数据库优化、第一阶段的性能分析数据
- 输出:优化后的后端代码、缓存实现、API 改进、弹性模式
### 6. 微服务与分布式系统优化
- 使用 Task 工具,subagent_type="performance-engineer"
- 提示词:优化 "$ARGUMENTS" 的分布式系统性能。分析服务间通信,实现服务网格优化,优化消息队列性能(Kafka/RabbitMQ),减少网络跳转。实现分布式缓存策略,优化序列化/反序列化。
- 上下文:来自步骤 5 的后端优化
- 输出:服务通信改进、消息队列优化、分布式缓存配置
## 第三阶段:前端与 CDN 优化
### 7. 前端打包与加载优化
- 使用 Task 工具,subagent_type="frontend-developer"
- 提示词:针对核心网页指标 {context_from_phase_1},优化 "$ARGUMENTS" 的前端性能。实现代码分割、摇树优化、懒加载和动态导入。通过 webpack/rollup 分析优化打包体积。实现资源提示(prefetch、preconnect、preload)。优化关键渲染路径,消除阻塞渲染的资源。
- 上下文:来自第一阶段的用户体验分析、来自第二阶段的后端优化
- 输出:优化后的打包、懒加载实现、改进的核心网页指标
### 8. CDN 与边缘优化
- 使用 Task 工具,subagent_type="cloud-infrastructure::cloud-architect"
- 提示词:优化 "$ARGUMENTS" 的 CDN 和边缘性能。配置 CloudFlare/CloudFront 以实现最佳缓存,为动态内容实现边缘函数,使用响应式图片以及 WebP/AVIF 格式进行图片优化。配置 HTTP/2 和 HTTP/3,实现 Brotli 压缩。为全球用户设置地理分布。
- 上下文:来自步骤 7 的前端优化
- 输出:CDN 配置、边缘缓存规则、压缩配置、地理优化
### 9. 移动端与渐进式 Web 应用优化
- 使用 Task 工具,subagent_type="frontend-mobile-development::mobile-developer"
- 提示词:优化 "$ARGUMENTS" 的移动端体验。实现 Service Worker 以支持离线功能,通过自适应加载优化弱网环境。减少移动端 CPU 上的 JavaScript 执行时间。为长列表实现虚拟滚动。优化触控响应和流畅动画。如果适用,考虑 React Native/Flutter 的特定优化。
- 上下文:来自步骤 7-8 的前端优化
- 输出:移动端优化代码、PWA 实现、离线功能
## 第四阶段:负载测试与验证
### 10. 全面负载测试
- 使用 Task 工具,subagent_type="performance-engineer"
- 提示词:使用 k6/Gatling/Artillery 对 "$ARGUMENTS" 进行全面负载测试。基于生产流量模式设计真实的负载场景。测试正常负载、峰值负载和压力场景。如果适用,包括 API 测试、基于浏览器的测试和 WebSocket 测试。在不同负载水平下测量响应时间、吞吐量、错误率和资源利用率。
- 上下文:来自第一至第三阶段的所有优化
- 输出:负载测试结果、负载下的性能表现、崩溃点、可扩展性分析
### 11. 性能回归测试
- 使用 Task 工具,subagent_type="performance-testing-review::test-automator"
- 提示词:为 "$ARGUMENTS" 创建自动化性能回归测试。为关键指标设置性能预算,使用 GitHub Actions 或类似工具集成到 CI/CD 流水线。创建前端 Lighthouse CI 测试、基于 Artillery 的 API 性能测试以及数据库性能基准测试。实现针对性能回退的自动回滚触发器。
- 上下文:来自步骤 10 的负载测试结果、第一阶段的基础指标
- 输出:性能测试套件、CI/CD 集成、回归预防系统
## 第五阶段:监控与持续优化
### 12. 生产监控搭建
- 使用 Task 工具,subagent_type="observability-engineer"
- 提示词:为 "$ARGUMENTS" 实施生产性能监控。使用 DataDog/New Relic/Dynatrace 搭建 APM,配置基于 OpenTelemetry 的分布式链路追踪,实现自定义业务指标。为关键指标创建 Grafana 仪表板,为性能退化设置 PagerDuty 告警。为关键服务定义 SLI/SLO 及错误预算。
- 上下文:来自所有先前阶段的性能改进
- 输出:监控仪表板、告警规则、SLI/SLO 定义、Runbook
### 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 < 200msP95 < 1sP99 < 2s
- **核心网页指标**LCP < 2.5sFID < 100msCLS < 0.1
- **吞吐量**:支持当前峰值负载的 2 倍,且错误率 < 1%
- **数据库性能**:查询 P95 < 100ms,无超过 1s 的查询
- **资源利用率**:正常负载下 CPU < 70%,内存 < 80%
- **成本效率**:每美元性能提升至少 30%
- **监控覆盖率**:100% 的关键路径已埋点并配置告警
性能优化目标:$ARGUMENTS
## 限制说明
- 仅当任务明确符合上述范围时使用此技能。
- 请勿将输出视为环境特定验证、测试或专家评审的替代方案。
- 如果缺少必需的输入、权限、安全边界或成功标准,请停止并向用户请求澄清。