chore: import zh skill application-performance-performance-optimization
This commit is contained in:
@@ -0,0 +1,9 @@
|
||||
# WeHub 来源说明
|
||||
|
||||
- Skill 名称:`application-performance-performance-optimization`
|
||||
- 中文类目:端到端性能分析与压测
|
||||
- 上游仓库:`sickn33__antigravity-awesome-skills`
|
||||
- 上游路径:`plugins/antigravity-awesome-skills-claude/skills/application-performance-performance-optimization/SKILL.md`
|
||||
- 上游链接:https://github.com/sickn33/antigravity-awesome-skills/blob/HEAD/plugins/antigravity-awesome-skills-claude/skills/application-performance-performance-optimization/SKILL.md
|
||||
- 本仓库为 WeHub 中文 Skill 汉化包,基于 skill 市场筛选 Top200 清单整理
|
||||
- 原作者、版权和许可证信息以上游仓库为准
|
||||
@@ -0,0 +1,162 @@
|
||||
---
|
||||
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 < 200ms,P95 < 1s,P99 < 2s
|
||||
- **核心网页指标**:LCP < 2.5s,FID < 100ms,CLS < 0.1
|
||||
- **吞吐量**:支持当前峰值负载的 2 倍,且错误率 < 1%
|
||||
- **数据库性能**:查询 P95 < 100ms,无超过 1s 的查询
|
||||
- **资源利用率**:正常负载下 CPU < 70%,内存 < 80%
|
||||
- **成本效率**:每美元性能提升至少 30%
|
||||
- **监控覆盖率**:100% 的关键路径已埋点并配置告警
|
||||
|
||||
性能优化目标:$ARGUMENTS
|
||||
|
||||
## 限制说明
|
||||
- 仅当任务明确符合上述范围时使用此技能。
|
||||
- 请勿将输出视为环境特定验证、测试或专家评审的替代方案。
|
||||
- 如果缺少必需的输入、权限、安全边界或成功标准,请停止并向用户请求澄清。
|
||||
Reference in New Issue
Block a user