performance-efficiency

性能效率评估

第 1 步：收集上下文

询问用户：

您希望我评估哪项工作负载的性能效率？请提供：

• 工作负载名称以及要分析的代码包／目录
• 性能要求（延迟目标、吞吐量需求、并发用户数）
• 已知瓶颈（可选——您怀疑性能不佳的部分）

如果已提供上下文，或您当前位于代码库中，请直接继续。

第 2 步：计算资源选择发现

分析计算资源的选择和配置。

您 MUST 检查：

• EC2 实例类型和系列（通用型与计算／内存／存储优化型）
• Lambda 内存和超时配置
• ECS/Fargate 任务的 CPU 和内存分配
• 容器基础镜像（Alpine、distroless、完整操作系统）
• Graviton（ARM）与 x86 架构的选择
• 预置并发配置（Lambda）
• 批处理与实时处理的选择

对于每项计算资源，请记录：

• 文件路径和行号
• 实例类型／规格，以及可能适用或不适用的原因
• 相对于工作负载类型的内存／CPU 比例
• 冷启动影响（Lambda、Fargate）

您 MUST 标记：

• 使用默认 128MB 内存的 Lambda（可能资源不足，执行速度较慢）
• Lambda 超时时间 ≥ 调用方的超时时间（调用方始终会将其视为超时）
• 面向计算密集型或内存密集型工作负载使用通用型实例
• 在 Graviton 能提供更优性价比的情况下使用 x86
• 过度配置的 Fargate 任务（简单工作负载却分配了大量 CPU／内存）

第 3 步：存储和数据库性能发现

分析存储和数据库配置的性能。

您 MUST 检查：

• 数据库引擎选择是否符合访问模式
• 只读副本配置
• 连接池（RDS Proxy、应用级连接池）
• DynamoDB 表设计（分区键分布、GSI 配置）
• 缓存层（ElastiCache、DAX、CloudFront）
• S3 访问模式和请求速率注意事项
• EBS 卷类型和 IOPS 配置
• 应用代码中的数据库查询模式（N+1 查询、缺少索引）

您 MUST 标记：

• 对键值访问模式使用关系型数据库（DynamoDB 会更合适）
• 无服务器架构连接 RDS 时未使用连接池
• DynamoDB 存在热分区模式（键设计不佳）
• 对读取频繁且数据变更较少的内容未设置缓存层
• gp2 EBS 卷（gp3 能以更低成本提供更优的基础性能）
• DynamoDB 读取频繁的场景缺少 DAX
• 应用代码存在 N+1 查询模式或无界查询

第 4 步：网络和内容分发发现

分析网络配置的性能。

您 MUST 检查：

• CloudFront 分配（或静态内容／API 内容未使用 CloudFront 的情况）
• API Gateway 缓存配置
• VPC 端点的使用情况（相比互联网路径可降低延迟）
• 延迟敏感型工作负载的置放群组
• Global Accelerator 配置
• 连接设置（keep-alive、HTTP/2、压缩）
• DNS 解析（Route 53 基于延迟的路由）

您 MUST 标记：

• 静态内容分发未使用 CDN
• API 响应未压缩（gzip/brotli）
• 可缓存的 GET 端点未使用 API Gateway 缓存
• 可通过本地区域端点处理的跨区域调用
• 缺少 VPC 端点（会增加 NAT Gateway 延迟）

步骤 5：扩展性与弹性发现

分析扩展配置和响应能力。

你必须检查：

• Auto Scaling 策略（目标跟踪与步进式扩展）
• 使用的扩展指标（仅 CPU，还是队列深度、延迟等自定义指标）
• 冷却期和扩展速度
• 针对可预测模式的计划扩展
• 对延迟敏感的 Lambda 函数是否使用预置并发
• 数据库自动扩展（Aurora、DynamoDB）
• 扩展瓶颈（连接限制、DNS 传播、冷启动）

你必须标记：

• 仅使用 CPU 扩展指标（忽略内存、队列深度和延迟）
• 阻碍快速响应的长冷却期
• 对延迟敏感的 Lambda 函数未使用预置并发
• 负载模式多变但数据库容量固定
• 扩展上限过低，无法满足预期峰值

步骤 6：应用性能模式发现

分析应用代码中的性能模式。

你必须检查：

• 同步与异步处理模式
• 批处理机会（批量写入、批量 API）
• 分页实现（游标与偏移量）
• 数据序列化格式（JSON 与二进制协议）
• 应用代码中的缓存用法（本地缓存、分布式缓存）
• 预热和连接复用模式（在 Lambda 处理程序之外定义处理程序）
• 独立操作采用并行还是顺序处理

你必须标记：

• 可以改为异步处理的同步处理（SQS、EventBridge）
• 可以并行执行的顺序 API 调用
• 大型数据集使用基于偏移量的分页（基于游标的分页复杂度为 O(1)）
• Lambda 冷启动模式（在处理程序中而非模块作用域初始化）
• 缺少批量操作（逐条使用 PutItem，而非 BatchWriteItem）
• 未分页的无界数据检索

步骤 7：监控与优化实践

分析性能监控配置。

你必须检查：

• CloudWatch 指标和警报（延迟百分位数、错误）
• X-Ray/OpenTelemetry 跟踪配置
• 对性能敏感操作的自定义指标
• 性能预算和警报
• 跟踪延迟/吞吐量的仪表板定义

你必须标记：

• 未按 p95/p99 级别监控延迟
• 服务边界之间没有分布式跟踪
• 没有性能警报（只有错误警报）
• 仅有平均值指标（无法发现尾延迟问题）

---STOP--- 检查点：发现工作已完成 — 可以根据 WA Framework 进行评估

已发现计算资源选择（{X} 个资源）、存储/数据库配置、网络模式、扩展策略、应用性能模式，以及 {packages analyzed} 中的监控设置。

是否继续根据 WA Performance Efficiency 支柱问题评估这些发现并评定风险等级？

在用户明确确认之前，请勿继续。

---

步骤 8：根据 WA Framework 问题进行评估

针对每个问题，请提供：状态、证据（文件:行号）、差距、风险。

PERF 1 — 如何选择合适的云资源？

• 证据：实例类型、计算系列、存储层级、选择理由

PERF 2 — 如何选择计算解决方案？

• 证据：Lambda 与 ECS、EC2 的选择，内存/CPU 配置，冷启动处理

PERF 3 — 如何选择存储解决方案？

• 证据：与访问模式匹配的存储类型、IOPS 配置、分层

PERF 4 — 如何选择数据库解决方案？

• 证据：引擎选择、只读副本、连接池、缓存层

PERF 5 — 如何配置网络解决方案？

• 证据：CloudFront、VPC 端点、置放群组、压缩

PERF 6 — 如何演进工作负载以利用新版本？

• 证据：运行时版本、SDK 版本、Graviton 采用情况、现代功能

PERF 7 — 如何监控资源以确保其性能良好？

• 证据：按百分位数统计的延迟指标、吞吐量跟踪、性能警报

PERF 8 — 如何权衡取舍以提升性能？

• 证据：缓存策略、异步模式、最终一致性选择

步骤 9：风险评估

针对每项发现，使用影响 × 可能性进行评估：

影响：轻微（略有不足，不会对用户造成可见影响）| 中等（延迟明显，在负载下体验下降）| 严重（面向用户的请求超时、请求丢失、违反 SLA）

可能性：低（仅影响边缘情况或极端负载）| 中（影响正常峰值负载）| 高（影响稳定状态下的流量）

影响	可能性	风险级别
严重	高	严重
严重	中	高
严重	低	高
中等	高	高
中等	中	中
中等	低	中
轻微	高	中
轻微	中	低
轻微	低	低

---STOP--- 检查点：风险评估已完成 — 已准备好生成最终报告

已评估计算资源选型、存储/数据库、网络、扩展、应用模式和监控方面的 {N} 项发现。风险分布：{X} 项严重、{Y} 项高、{Z} 项中、{W} 项低。已识别关键性能瓶颈并估算改进幅度。

要我生成完整的性能效率评估和按优先级排序的修复计划吗？

在用户明确确认之前，请勿继续。

---

步骤 10：生成发现

# Performance Efficiency Assessment: {Workload Name}

## Executive Summary
- **Date**: {date}
- **Packages Analyzed**: {list}
- **Performance Target**: {latency/throughput targets if specified}
- **Findings**: {X} Critical, {Y} High, {Z} Medium, {W} Low
- **Overall Performance Maturity**: {1-5} — {one-line justification}

## Performance Scorecard
| Domain | Score (1-5) | Key Strength | Key Gap |
|--------|-------------|--------------|---------|
| Compute Selection | {score} | {strength} | {gap} |
| Storage & Database | {score} | {strength} | {gap} |
| Networking & CDN | {score} | {strength} | {gap} |
| Scaling & Elasticity | {score} | {strength} | {gap} |
| Application Patterns | {score} | {strength} | {gap} |
| Monitoring | {score} | {strength} | {gap} |

## Critical and High Risk Findings
{For each: ID, domain, title, description, evidence (file:line), performance impact, recommendation, expected improvement, effort, AWS services}

## Medium Risk Findings
{Same format, condensed}

## Low Risk Findings
{Summary table: ID | Domain | Title | Recommendation}

## Optimization Opportunities
| Resource | Current Config | Recommended | Expected Improvement | Evidence |
|----------|---------------|-------------|---------------------|----------|
| {resource} | {current} | {optimized} | {improvement} | {file:line} |

## Prioritized Remediation Plan

### Quick Wins (< 1 week)
| Finding | Action | Performance Impact | Effort |
|---------|--------|-------------------|--------|
{Increase Lambda memory, enable compression, add gp3, enable keep-alive}

### Foundation (1-4 weeks)
| Finding | Action | Performance Impact | Effort | Dependencies |
|---------|--------|-------------------|--------|--------------|
{Add caching layer, implement connection pooling, CDN, async patterns}

### Strategic (1-3 months)
| Finding | Action | Performance Impact | Effort | Dependencies |
|---------|--------|-------------------|--------|--------------|
{Database migration, architecture rework, global distribution, Graviton migration}

## Next Steps
{Top 5 concrete performance actions the team should take this week}

步骤 11：提供后续帮助

交付评估后，提供以下选项：

您希望我：

• 为特定数据流设计缓存策略？
• 使用功率调优方法优化 Lambda 内存/超时配置？
• 为无服务器 → RDS 实现连接池？
• 制定包含目标场景的负载测试计划？
• 将同步代码路径重构为使用队列的异步路径？
• 为您的 API/静态内容配置 CloudFront 分发？

校准指南

• 如果工作负载采用了适当的实例类型、缓存、CDN、自动扩缩和延迟监控，则属于成熟状态——重点关注尾延迟、高级缓存和架构优化
• 每项发现都必须有代码证据——未经检查现有缓存层，不要标记“缺少缓存”
• 性能发现应估算改进幅度（例如：“添加连接池通常可将 p99 延迟降低 30-50%”）
• 始终评估权衡：性能优化可能会增加成本或复杂性
• 当需要实际性能数据时，“无法确定”是有效结论（例如，实例是否受 CPU 限制需要通过 CloudWatch 指标判断）
• 在列出问题之前，先肯定良好的性能实践