背景:大促前的压测暴露了长尾 八月底大促压测,核心的下单查询接口平均 RT 只有 120ms,看着挺好,但 P99 飙到 800ms,监控里偶发还有 1.5 秒的尖刺。平均好看掩盖了长尾,而用户体验恰恰被那 1% 的慢请求毁掉。我接了这活,目标是把 P99 压到 150ms 以内。 全链路耗时分析:
把线程池换成虚拟线程 我们有个网关聚合服务,每请求要并发调 5 个下游,原来用 200 个平台线程的池子,峰值打满就排队。用户多的时候,线程池耗尽,请求在队列里干等,RT 从 200ms 飙到 2 秒。听说 JDK 19 的虚拟线程能把"一个任务一个线程"做到近乎免费,就拿来做了对照实验,想看看是不
那个 3000 行的 Service 接手交易核心模块时,OrderService.java 有 3128 行,下了 47 个 @Autowired 的 DAO 和远程 client。任何一处改动我都得屏住呼吸。上周一个改下单幂等的小需求,回归测试就跑了三轮,改动 8 行、提心吊胆一整天。更糟的是,
商品详情页 P99 1.8 秒,五个 RPC 串行调用 12 月中旬,前端同学甩过来一张截图:商品详情页首屏白屏 2 秒多,用户投诉"点商品没反应"。我去看 SkyWalking 的拓扑,这个接口平均 690 ms,P99 1.8 s,P999 3.2 s。 接口干的事很简单,串着调了 5 个下游:
运营说:这个报表等到花儿都谢了 十一月底,运营同学提了个工单:"销售明细报表要等 8 秒以上,导出的时候更是直接超时。" 我看了下 slow log,那条查询平均 8.4 秒,最慢的一次 21 秒: # Time: 2020-11-24T14:22:31.882113+08:00 # User@Ho