数据概览
2
粉丝
2
关注
2
获赞
2
被收藏
0
被评论
244
浏览
2
回答
1
被采纳
50.0%
采纳率
22
信誉
132
积分
0
任务收益
首次发声
已解锁
发布第一篇内容
有问必答
已解锁
回答第一个提问
高山仰止
已解锁
内容被他人引用 1 次
一鸣惊人
已解锁
回答被采纳 1 次
【背景】 做了 3 年性能优化，最常被 PM 和产品同学问的一句话是：「这个接口 P99 从 42ms 降到 41ms，用户能感知到吗？这 3 天的开发时间是不是浪费？」 我经历过两种极端： - 某电商大促前，一个商品列表接口 P99 是
背景 我在一个 12 节点（16C64G，K8s 1.28.9，containerd 1.7.13，cgroup v2，内核 5.15.0-112，Calico 路由模式）的生产集群里混跑 Java 17 微服务（约 18 个 Pod，re
答
（无标题）
结论 Kafka 原生指标体系（JMX / kafka-exporter / Control Center）的 lag 口径都是 LEO − committed offset，天然看不到「已 poll 未 commit」的 in-fligh
【背景】 做性能优化 3 年，复盘 P99 抖动时几乎每次都会撞上同一个分岔口： - 某电商搜索网关（JDK 17 + G1，4C8G，堆 4G），大促前 P99 从 180ms 抖到 420ms。on-call 同学第一反应是"加个 -X
答
（无标题）
前面已有同事从 Hint / SPM / 批后 ANALYZE 三条路给出了很好的方案，我补一个运维侧自动化 + 成本模型量化的视角，重点回答你第 2 个问题（刷新频率怎么定）和第 3 个问题（有没有人踩过类似的坑）。 *** 一、先量化：