背景:大促前的压测暴露了长尾 八月底大促压测,核心的下单查询接口平均 RT 只有 120ms,看着挺好,但 P99 飙到 800ms,监控里偶发还有 1.5 秒的尖刺。平均好看掩盖了长尾,而用户体验恰恰被那 1% 的慢请求毁掉。我接了这活,目标是把 P99 压到 150ms 以内。 全链路耗时分析:
目标:大促前把商品详情接口压到 8000 QPS 9 月 20 号拿到大促的容量需求:商品详情接口要扛 8000 QPS,P99 控制在 300 ms 以内。第一次压测跑下来只有 2000 QPS,P99 1.2 秒,差了 4 倍。 前后两周五轮优化,最后压到 8200 QPS、P99 178 ms
商家后台一个接口 2.3 秒,被投诉了半年 3 月上旬,客服转过来一条工单:某连锁商家反馈"经营概览"页面打开要转好几秒,用了半年一直这样。 我复现了一下,确实慢。这个接口返回商家今日/本月/累计的订单量、销售额、退款率、热销商品 Top5、会员增长数,一共 9 个指标。 第一步永远是耗时拆解,不是
一个批量接口慢在哪:不是 Redis 慢,是网络慢 八月下旬优化一个批量查询接口。它要一次读 200 个商品的库存,我一开始的写法很直白: public Map<String, Integer> batchGetStock(List<String> skuIds) { Map<String,