mcpField
A
application-performance-performance-optimization

application-performance-performance-optimization

github.com/sickn33开发48.7k441 次安装今天更新
代码仓库

关于 application-performance-performance-optimization

此 Skill 用于协调后端、前端和基础设施的端到端应用性能工作,涵盖基准分析、分阶段优化、负载测试验证与持续监控,并强调依据环境数据验证及安全防护。

主要功能

  1. 01设定性能目标并建立基准
  2. 02分析可观测性与用户体验
  3. 03优化后端、数据库和前端
  4. 04负载测试与回归防护
  5. 05生产监控与持续调优

适用场景

  1. 01定位应用各层的性能瓶颈
  2. 02依据负载和目标规划容量
  3. 03通过负载及回归测试验证改动

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/sickn33/agentic-awesome-skills --skill application-performance-performance-optimization

安装后在 Claude Code 中输入/application-performance-performance-optimization确认已加载。

详细介绍

使用专用的性能优化 Agent,端到端地优化应用性能:

[Extended thinking: 此工作流编排了覆盖整个应用技术栈的综合性能优化流程。工作流从深入分析和建立基线开始,逐步对各系统层进行有针对性的优化,通过负载测试验证改进效果,并建立持续监控以维持性能。每个阶段都基于前一阶段的发现,制定数据驱动的优化策略,解决实际瓶颈,而非追求理论上的改进。工作流强调现代可观测性实践、以用户为中心的性能指标,以及经济高效的优化策略。]

在以下情况下使用此技能

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

在以下情况下不要使用此技能

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

指定的 Task 工具和 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、INP、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"

成功标准示例

测试前应就特定工作负载的目标达成一致;以下数值仅为示例,并非通用要求或承诺的改进幅度。按实测访问量的第 75 百分位评估 Core Web Vitals,并区分移动端和桌面端。INP 已取代 FID;仅凭实验室环境中的加载耗时无法衡量真实交互响应能力。

  • 响应时间:关键端点的 P50 < 200ms,P95 < 1s,P99 < 2s
  • Core Web Vitals:LCP < 2.5s,INP ≤ 200ms,CLS < 0.1
  • 吞吐量:在错误率 <1% 的情况下支持当前峰值负载的 2 倍
  • 数据库性能:查询 P95 < 100ms,且无耗时 > 1s 的查询
  • 资源利用率:正常负载下,CPU < 70%,内存 < 80%
  • 成本效益:每美元对应的性能至少提升 30%
  • 监控覆盖率:100% 的关键路径均已埋点并配置告警

性能优化目标:$ARGUMENTS

示例

用户请求:

协调后端、前端和基础设施的性能优化。

限制

  • 仅当任务明确符合上述范围时,才使用此技能。
  • 不要将输出视为特定环境验证、测试或专家评审的替代品。
  • 如果缺少必需的输入、权限、安全边界或成功标准,请停止并请求澄清。

评论

支持 Markdown