延迟预算Skill latency-budget

---

名称: 延迟预算 描述: 计算和分配系统的延迟预算 - 将端到端延迟分解为组件预算并提供优化建议 允许的工具: Read, Glob, Grep, Task, AskUserQuestion 参数提示: <目标延迟> [系统描述或文件]

延迟预算命令

此命令计算和分配系统的延迟预算，帮助团队理解时间消耗和达到延迟目标。

目的

提供延迟预算分析，包括：

1. 端到端延迟分解
2. 每个组件的预算分配
3. 瓶颈识别
4. 优化建议
5. 延迟监控策略

工作流程

第 1 阶段: 需求收集

如果提供了目标延迟和系统：

• 解析延迟目标（例如，“100ms”、“500ms P99”）
• 在代码库中搜索系统架构
• 识别请求路径中的组件

如果未提供，询问：

延迟预算分析设置：

1. 目标延迟：
   - P50 目标：[例如，50ms、100ms、200ms]
   - P99 目标：[例如，100ms、200ms、500ms]

2. 请求类型：
   - 读取路径（查询、获取、搜索）
   - 写入路径（创建、更新、删除）
   - 混合（读取和写入）

3. 系统范围：
   - 单个服务延迟
   - 端到端用户请求
   - 特定流程（例如，“结账”、“搜索”）

4. 当前状态（如果已知）：
   - 当前 P50：[值]
   - 当前 P99：[值]
   - 已知瓶颈：[组件]

第 2 阶段: 组件识别

识别请求路径中的所有组件：

请求路径分析：

┌─────────────────────────────────────────────────────────────┐
│                      请求流程                            │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  客户端 ──► CDN ──► 负载均衡器 ──► API ──► 服务 ──► 数据库          │
│    │        │       │      │        │          │            │
│    ▼        ▼       ▼      ▼        ▼          ▼            │
│  [?ms]    [?ms]   [?ms]  [?ms]    [?ms]      [?ms]         │
│                                                              │
└─────────────────────────────────────────────────────────────┘

识别的组件：

1. 网络段
   □ 客户端 → CDN/边缘
   □ CDN → 负载均衡器
   □ 负载均衡器 → API 网关
   □ API 网关 → 服务
   □ 服务 → 数据库

2. 处理组件
   □ CDN 处理
   □ 负载均衡器路由
   □ API 网关（认证、限流）
   □ 服务逻辑
   □ 数据库查询

3. 外部依赖
   □ 第三方 API
   □ 缓存查找
   □ 消息队列操作

第 3 阶段: 预算分配

跨组件分配延迟预算：

延迟预算分配

目标：[X]ms P99 端到端

═══════════════════════════════════════════════════════════════

                    预算分解

  ┌────────────────────────────────────────────────────────┐
  │                    [总计]ms                            │
  ├────────────────────────────────────────────────────────┤
  │                                                         │
  │  ┌──────┬──────┬──────┬──────┬──────┬──────┐          │
  │  │网络│ 边缘 │  负载均衡器  │ API  │服务│  数据库  │          │
  │  │ Xms  │ Xms  │ Xms  │ Xms  │ Xms   │ Xms  │          │
  │  └──────┴──────┴──────┴──────┴──────┴──────┘          │
  │                                                         │
  │  分配：                                            │
  │  ├── 网络（客户端 → 边缘）：     [X]ms  ([Y]%)        │
  │  ├── 边缘/CDN 处理：         [X]ms  ([Y]%)        │
  │  ├── 负载均衡器：               [X]ms  ([Y]%)        │
  │  ├── API 网关：                 [X]ms  ([Y]%)        │
  │  ├── 服务处理：          [X]ms  ([Y]%)        │
  │  ├── 数据库查询：              [X]ms  ([Y]%)        │
  │  └── 响应序列化：      [X]ms  ([Y]%)        │
  │                                                         │
  │  缓冲/松弛：                    [X]ms  ([Y]%)        │
  │                                                         │
  └────────────────────────────────────────────────────────┘

每个组件的预算：

| 组件 | 预算 | 典型值 | 备注 |
|-----------|--------|---------|-------|
| 网络 RTT | [X]ms | 10-50ms | 根据地理位置变化 |
| CDN/边缘 | [X]ms | 5-20ms | 缓存命中 vs 未命中 |
| 负载均衡器 | [X]ms | 1-5ms | 通常最小 |
| API 网关 | [X]ms | 5-20ms | 认证、限流 |
| 服务逻辑 | [X]ms | 10-100ms | 主要应用 |
| 数据库 | [X]ms | 5-50ms | 查询依赖 |
| 序列化 | [X]ms | 1-10ms | 响应大小依赖 |

第 4 阶段: 延迟参考数据

提供现实估计的参考数据：

延迟参考数字（2024）：

网络延迟：
├── 同一数据中心：0.5ms
├── 同一区域（跨可用区）：1-2ms
├── 跨区域（同一大陆）：30-100ms
├── 跨大陆：100-300ms
└── 客户端 → 最近边缘：10-50ms（变化）

服务延迟（P99）：
├── Redis 缓存命中：0.5-2ms
├── Memcached 缓存命中：0.5-2ms
├── PostgreSQL 简单查询：2-10ms
├── PostgreSQL 复杂查询：10-100ms
├── Elasticsearch 搜索：10-50ms
├── Kafka 生产（ack=1）：2-10ms
└── HTTP 调用到另一个服务：10-100ms

处理延迟：
├── JSON 序列化（1KB）：0.1-1ms
├── JWT 验证：0.5-2ms
├── 连接池获取：0.1-1ms
└── 上下文切换：0.01ms

地理示例：
├── 美国东部 → 美国西部：60-80ms
├── 美国 → 欧洲：80-120ms
├── 美国 → 亚洲：150-250ms
└── 欧洲 → 亚洲：150-300ms

第 5 阶段: 优化建议

基于预算分配和瓶颈：

延迟优化建议

优先级 1: 快速获胜
─────────────────────────────────────────────────────────────
[ ] 添加缓存层
    当前：[X]ms 数据库查询
    目标：[Y]ms 缓存命中
    节省：~[Z]ms

[ ] 连接池
    当前：每个请求新连接
    目标：持久连接池
    节省：~[Z]ms

优先级 2: 架构变更
─────────────────────────────────────────────────────────────
[ ] 添加边缘缓存
    当前：所有请求命中源
    目标：80% 边缘缓存命中
    节省：~[Z]ms P50

[ ] 异步处理
    当前：同步完整处理
    目标：延迟非关键工作
    节省：~[Z]ms

优先级 3: 基础设施
─────────────────────────────────────────────────────────────
[ ] 部署到额外区域
    当前：单区域
    目标：多区域
    节省：~[Z]ms 为远程用户

[ ] 升级数据库层
    当前：[层]
    目标：[更高层]
    节省：~[Z]ms 查询时间

估计影响：

| 优化 | 努力 | P50 节省 | P99 节省 |
|--------------|--------|-------------|-------------|
| [优化 1] | 低 | [X]ms | [Y]ms |
| [优化 2] | 中 | [X]ms | [Y]ms |
| [优化 3] | 高 | [X]ms | [Y]ms |

第 6 阶段: 监控策略

定义如何监控延迟预算：

延迟监控策略

每个组件的指标：

| 组件 | 指标名称 | 警报阈值 |
|-----------|-------------|-----------------|
| 总计 | request_latency_p99 | > [目标]ms |
| 数据库 | db_query_latency_p99 | > [预算]ms |
| 缓存 | cache_latency_p99 | > [预算]ms |
| 外部 | external_api_p99 | > [预算]ms |

仪表板面板：

1. 端到端延迟（P50、P90、P99）
2. 组件分解（堆叠）
3. 预算消耗（已用预算百分比）
4. 地理分布

警报规则：

1. P99 > 目标
   - 条件：request_latency_p99 > [目标]ms 持续 5 分钟
   - 严重性：警告

2. P99 > 1.5x 目标
   - 条件：request_latency_p99 > [1.5x 目标]ms 持续 2 分钟
   - 严重性：严重

3. 组件预算超出
   - 条件：[组件]_latency_p99 > [预算]ms 持续 5 分钟
   - 严重性：警告

第 7 阶段: 生成报告

生成完整的延迟预算报告：

# 延迟预算报告：[系统名称]

## 执行摘要

目标延迟：[X]ms P99
当前状态：[Y]ms P99（如果已知）
差距：[Z]ms

## 请求流程

[带延迟的请求路径 ASCII 图]

## 预算分配

[组件预算表]

## 瓶颈分析

1. [主要瓶颈]：[影响]
2. [次要瓶颈]：[影响]

## 优化路线图

### 第 1 阶段: 快速获胜（[X]ms 节省）
- [优化 1]
- [优化 2]

### 第 2 阶段: 中期（[X]ms 节省）
- [优化 1]
- [优化 2]

### 第 3 阶段: 长期（[X]ms 节省）
- [优化 1]
- [优化 2]

## 监控设置

[要实现的指标和警报]

## 下一步

1. [立即行动]
2. [短期行动]
3. [长期行动]

使用示例

# 用特定目标分析
/sd:latency-budget 100ms

# 用 P99 目标和系统上下文分析
/sd:latency-budget "200ms P99" @docs/api-architecture.md

# 分析特定流程
/sd:latency-budget 50ms "结账流程"

# 用当前测量分析
/sd:latency-budget "100ms 目标，当前在 180ms"

交互元素

使用 AskUserQuestion 来：

• 澄清延迟目标（P50 vs P99）
• 理解当前瓶颈
• 验证组件识别
• 确认优化优先级

输出

此命令生成：

1. 预算分解 - 每个组件的延迟分配
2. 瓶颈分析 - 时间消耗处
3. 优化路线图 - 优先改进
4. 监控策略 - 如何跟踪延迟

相关技能

此命令利用：

• latency-optimization - 延迟减少技术
• caching-strategies - 基于缓存的优化
• database-scaling - 数据库性能
• cdn-architecture - 边缘优化

相关代理

对于包括延迟的容量规划：

• capacity-planner - 粗略计算