背景
在高并发与性能调优的世界里，P99 和 P999 一直是讨论的焦点。我们经常看到团队为了降低 P99 而投入大量资源，但是否真的有必要？或者，是否应该更关注 P999？
原理与根因分析
P99 和 P999 是两种不同的统计口径。P99 表示 99% 的请求在某个时间范围内完成，而 P999 表示 99.9% 的请求。在实际业务中，P99 可能是核心业务的 SLA，而 P999 则是次要的。
具体做法
- 确定业务需求：了解业务对延迟的容忍度，确定 SLA。
- 分析数据：使用监控工具分析 P99 和 P999 的数据，了解其分布情况。
- 调整策略：根据分析结果，调整系统配置和资源分配。
踩过的坑
- 过度优化：一味追求 P99 的优化，忽略了 P999 的重要性。
- 样本不足：P999 的样本量不足，导致统计结果不准确。
- 资源浪费：为 P99 投入大量资源，但实际效果不佳。
结论与可复用清单
- 明确业务需求：确定 SLA，避免盲目优化。
- 数据驱动决策：通过监控工具分析数据，做出科学决策。
- 合理资源分配：根据需求和数据分析，合理分配资源。
具体细节
- P99 的优化：通过调整连接池大小、优化查询语句等手段降低 P99。
- P999 的分析：使用监控工具分析 P999 的数据，确保其样本量足够。
- 资源分配：根据 P99 和 P999 的分析结果，合理分配资源，避免浪费。
引用
- P99 每天固定时段从 6ms 跳到 420ms：vm.dirty_ratio 默认 20% 的 writeback 风暴与一组可复现的调参
- MySQL 主键策略对批量写入 P99 的影响：UUID 到雪花 ID 的 40 倍收益
- MySQL 连接数与 QPS 齐涨、P99 却飙 15 倍：InnoDB 锁排队下「加连接 = 加等待」的复盘
- 连接池不是越大越好：一次 P99 抖动的排查与调参
- softnet backlog 堆 240 万包：netdev_budget 打满导致的"队列型 P99 抖动"排障
标签
- 高并发
- 性能调优
- 长尾延迟
- SLA
- 可观测性
分类
- 后端
品牌
- Trae
版本
- 无
0赞
0收藏
0评论
1浏览