Back to Details

performance-efficiency

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Performance Efficiency Assessment

性能效率评估

Step 1: Gather context

步骤1：收集上下文

Ask the user:
What workload would you like me to assess for performance efficiency? Please share:
  • Architecture overview (compute, storage, database, networking services)
  • Performance requirements (latency targets, throughput needs, concurrent users)
  • Current baselines (p50/p95/p99 latency, request rates, error rates)
  • Known bottlenecks (optional — areas you suspect are underperforming)
If context is already provided, proceed directly.
询问用户：
您希望我评估哪个工作负载的性能效率？请分享以下信息：
  • 架构概述（计算、存储、数据库、网络服务）
  • 性能要求（延迟目标、吞吐量需求、并发用户数）
  • 当前基准指标（p50/p95/p99延迟、请求速率、错误率）
  • 已知瓶颈（可选——您怀疑性能不佳的领域）
如果已提供上下文，直接进入下一步。

Step 2: Evaluate resource selection

步骤2：评估资源选择

Classify findings by severity:
  • 🔴 Critical — actively causing user-facing performance degradation
  • 🟡 High — suboptimal performance, noticeable under load
  • 🟢 Medium — optimization opportunity, not yet impacting users
Assess whether optimal resource types are used:
  • Compute — Are instance types matched to workload characteristics? (compute-optimized vs memory-optimized vs general purpose, Graviton adoption)
  • Storage — Are storage tiers matched to access patterns? (gp3 vs io2, S3 classes, EFS vs FSx)
  • Database — Is the database engine appropriate for the access pattern? (relational vs key-value vs document vs graph vs time-series)
  • Networking — Are placement groups, enhanced networking, or accelerated transfers used where latency matters?
  • Accelerators — Are GPUs, Inferentia, or custom hardware used where applicable?
按严重程度对发现的问题分类：
  • 🔴 严重 —— 正在导致面向用户的性能下降
  • 🟡 高优先级 —— 性能不理想，负载下明显可见
  • 🟢 中等优先级 —— 存在优化机会，尚未影响用户
评估是否使用了最优资源类型：
  • 计算 —— 实例类型是否与工作负载特征匹配？（计算优化型 vs 内存优化型 vs 通用型，Graviton采用情况）
  • 存储 —— 存储层级是否与访问模式匹配？（gp3 vs io2，S3存储类，EFS vs FSx）
  • 数据库 —— 数据库引擎是否适合访问模式？（关系型 vs 键值型 vs 文档型 vs 图型 vs 时序型）
  • 网络 —— 在延迟敏感场景中是否使用了放置组、增强型网络或加速传输？
  • 加速器 —— 是否在适用场景使用了GPU、Inferentia或自定义硬件？

Step 3: Assess scaling and elasticity

步骤3：评估扩展性与弹性

Evaluate:
  • Is auto-scaling configured with metrics that reflect actual demand? (not just CPU — consider queue depth, request count, custom metrics)
  • Are scaling policies responsive enough? (target tracking vs step scaling, cooldown periods)
  • Is there pre-warming or scheduled scaling for predictable traffic patterns?
  • Are there scaling bottlenecks? (database connections, DNS propagation, cold starts)
  • Is the architecture designed to scale horizontally? (stateless compute, distributed caching)
评估以下内容：
  • 是否根据反映实际需求的指标配置了自动扩展？（不只是CPU——考虑队列深度、请求数、自定义指标）
  • 扩展策略是否足够响应？（目标追踪 vs 步进扩展，冷却周期）
  • 是否针对可预测的流量模式配置了预热或定时扩展？
  • 是否存在扩展瓶颈？（数据库连接、DNS传播、冷启动）
  • 架构是否设计为支持水平扩展？（无状态计算、分布式缓存）

Step 4: Evaluate caching strategy

步骤4：评估缓存策略

Assess:
  • Is data cached at the right layers? (CDN, API Gateway cache, application cache, database cache)
  • Are cache hit ratios monitored? What are they?
  • Is cache invalidation well-managed? (TTL-based, event-driven, or manual)
  • Are hot spots identified and mitigated? (DAX for DynamoDB, ElastiCache for session/query data)
  • Is content delivery optimized? (CloudFront with appropriate cache behaviors, edge functions)
评估以下内容：
  • 是否在正确的层级缓存数据？（CDN、API Gateway缓存、应用缓存、数据库缓存）
  • 是否监控缓存命中率？命中率是多少？
  • 缓存失效管理是否完善？（基于TTL、事件驱动或手动方式）
  • 是否识别并缓解了热点问题？（DynamoDB的DAX，会话/查询数据的ElastiCache）
  • 内容交付是否优化？（配置了合适缓存行为的CloudFront，边缘函数）

Step 5: Assess data and network optimization

步骤5：评估数据与网络优化

Evaluate:
  • Is data transfer minimized? (compression, pagination, field selection, binary protocols)
  • Are synchronous calls that could be async identified? (SQS, EventBridge, Step Functions)
  • Is connection management optimized? (connection pooling, keep-alive, HTTP/2)
  • Are queries optimized? (indexes, query plans, read replicas for read-heavy workloads)
  • Is data locality considered? (region selection, multi-region for global users)
评估以下内容：
  • 是否最小化了数据传输？（压缩、分页、字段选择、二进制协议）
  • 是否识别出可改为异步的同步调用？（SQS、EventBridge、Step Functions）
  • 连接管理是否优化？（连接池、长连接、HTTP/2）
  • 查询是否优化？（索引、查询计划、读密集型工作负载的只读副本）
  • 是否考虑了数据本地性？（区域选择、面向全球用户的多区域部署）

Step 6: Evaluate monitoring and optimization practices

步骤6：评估监控与优化实践

Assess:
  • Are performance metrics tracked at meaningful percentiles? (p50, p95, p99, not just averages)
  • Are there performance budgets and alerts?
  • Is load testing conducted regularly? (peak load, sustained load, spike scenarios)
  • Is there a process for reviewing and acting on performance data?
  • Are experiments conducted to evaluate new approaches? (A/B testing infrastructure changes)
评估以下内容：
  • 是否跟踪了有意义的百分位性能指标？（p50、p95、p99，不只是平均值）
  • 是否设置了性能预算和告警？
  • 是否定期进行负载测试？（峰值负载、持续负载、突发场景）
  • 是否有审查并基于性能数据采取行动的流程？
  • 是否开展实验以评估新方法？（基础设施变更的A/B测试）

Step 7: Produce findings

步骤7：生成评估结果

Output:
markdown
undefined
输出：
markdown
undefined

Performance Efficiency Assessment: {Workload Name}

性能效率评估：{工作负载名称}

Summary

摘要

  • Date: {date}
  • Latency target: {target} | Current: {p50/p95/p99}
  • Throughput target: {target} | Current: {actual}
  • Findings: {X} Critical, {Y} High, {Z} Medium
  • 日期：{日期}
  • 延迟目标：{目标值} | 当前值：{p50/p95/p99}
  • 吞吐量目标：{目标值} | 当前值：{实际值}
  • 发现问题：{X}个严重问题，{Y}个高优先级问题，{Z}个中等优先级问题

Performance Scorecard

性能评分卡

DomainScore (1-5)Key Gap
Resource Selection{score}{gap}
Scaling & Elasticity{score}{gap}
Caching{score}{gap}
Data & Network{score}{gap}
Monitoring & Optimization{score}{gap}
领域评分（1-5）主要差距
资源选择{评分}{差距描述}
扩展性与弹性{评分}{差距描述}
缓存策略{评分}{差距描述}
数据与网络{评分}{差距描述}
监控与优化实践{评分}{差距描述}

Critical Performance Issues

严重性能问题

{Each: what's bottlenecked, severity, impact on user experience, recommendation, expected improvement, AWS service}
{每个问题：瓶颈所在、严重程度、对用户体验的影响、建议、预期改进效果、AWS服务}

Optimization Opportunities

优化机会

Resource Selection

资源选择

ResourceCurrentRecommendedExpected ImprovementAWS Service
{resource}{current config}{recommended}{improvement}{service}
资源当前配置推荐配置预期改进效果AWS服务
{资源名称}{当前配置详情}{推荐配置}{改进效果}{服务名称}

Scaling Improvements

扩展性改进

{Each: current limitation, recommended change, AWS service, implementation approach}
{每个项：当前限制、推荐变更、AWS服务、实施方法}

Caching Opportunities

缓存优化机会

{Each: cache layer to add/improve, expected hit ratio, latency reduction, AWS service}
{每个项：需添加/改进的缓存层、预期命中率、延迟降低幅度、AWS服务}

Data and Network Optimizations

数据与网络优化

{Each: current pattern, optimized pattern, expected benefit, AWS service}
{每个项：当前模式、优化后模式、预期收益、AWS服务}

Remediation Plan

整改计划

Quick Wins (< 1 week)

快速见效项（<1周）

{Configuration changes, enabling features, easy right-sizing}
{配置变更、功能启用、轻松调整资源规格}

Foundation (1-4 weeks)

基础优化项（1-4周）

{Caching layers, scaling policies, monitoring improvements}
{缓存层搭建、扩展策略调整、监控改进}

Strategic (1-3 months)

战略优化项（1-3个月）

{Architecture changes, database migrations, global distribution}
{架构变更、数据库迁移、全球分布式部署}

Next Steps

下一步行动

{Concrete actions: load test scenarios to run, metrics to instrument, experiments to try}
undefined
{具体行动：需执行的负载测试场景、需采集的指标、需尝试的实验}
undefined

Step 8: Offer follow-up

步骤8：提供后续服务

After delivering the assessment, offer:
Would you like me to:
  • Deep-dive into a specific bottleneck?
  • Design a caching strategy for a particular data flow?
  • Create a load testing plan with target scenarios?
  • Evaluate alternative architectures for a specific component?
  • Model the performance impact of a scaling change?
交付评估结果后，提供以下选项：
您是否需要我：
  • 深入分析特定瓶颈？
  • 为特定数据流设计缓存策略？
  • 创建包含目标场景的负载测试计划？
  • 评估特定组件的替代架构？
  • 模拟扩展变更对性能的影响？