我们有3天时间来拯救MEP：从3.15秒降至233毫秒

Source: Dev.to

背景

我们在一个迁移项目的核心 API 上进行调优，该 API 存在严重的延迟问题，阻碍了上线：

• MongoDB CPU 饱和至 150%
• 连接峰值从 400 增至 1 500
• 错误率高
• 请求超过 30 秒

采用的做法

初步审查

• 分析代码以识别反模式和 quick wins。
• 使用 AI 加速器遍历整个代码库，识别反模式并记录 MongoDB 集合结构。
• Cynefin 框架：问题位于 Complex（复杂）象限 → 采用 Probe → Sense → Respond 方法。

第 1 阶段：首次测试（Probe）

• 负载概况：逐步提升至 500 虚拟用户，保持 15 分钟平台，然后下降。
• 结果：出现 504 错误，MongoDB 不稳定，场景复用相同标识符（写冲突），查询缺少索引。
• 响应：在关键字段上创建索引，随机化标识符，使用加权分布的参数，搭建专用预生产环境。
• AI：生成带随机化和加权分布的测试脚本。

第 2 阶段：修正后测试（Probe）

• 获得的基准：101 req/s，错误率 2.56%，P99 = 9.9 s，平均 = 3.15 s。

Kubernetes 自动伸缩

• 改进 HPA 并增加副本数。
• 结果：82 req/s，错误率 4.17%，P99 = 12.3 s，平均 = 4.09 s → 回退（副本增多导致 MongoDB 并发连接增多）。

增加 Pod 资源

• 提升 CPU 与 RAM。
• 结果：162 req/s，错误率 0.68%，P99 = 5.86 s，平均 = 1.58 s → 吞吐提升 60%，错误率下降 73%，但延迟仍高（代码层面问题）。

第 3 阶段：代码 & 数据库优化

• 用并发查询 + 应用层合并取代 $lookup。
• 将 O(n²) 循环重构为 O(n)，使用 Map/字典。
• 优化 write concern（w:1，仅主节点）。
• 修复 N+1 模式（将单次调用改为批量 $in）。
• AI：生成特征化测试，重写 $lookup 流水线，重构循环。

最终测试（Probe）

• 最终结果：200 req/s，≈0% 错误，P99 = 0.67 s，平均 = 233 ms。
• 吞吐比基准翻倍，P99 延迟从 9.9 s 降至 0.67 s。

经验教训

• 每次改动前后都要测量：直觉不足以判断。
• 代表性的测试场景：不真实的场景会产生误导性结果。
• 跨层次的导航：基础设施、代码和数据库构成互联系统。
• 合适的工具：负载测试、可观测性和性能分析是必不可少的。
• AI 代理：加速循环，但不能取代人工专业知识。
• 停止准则：SLO 定义系统何时“足够好”，以避免过度优化。

附加

成熟的 Platform Engineering 组织是确保优化收益能够长期落地的关键前提。