语义缓存上线一个月,命中率 8.3% 三月份我们给客服 Agent 上了语义缓存,预期是「相似问题不用重复问模型,能省一大笔钱」。上线一个月看数据,命中率 8.3%,省下的钱还不够维护缓存本身的成本。 这篇文章记录我们怎么把命中率从 8.3% 提到 41%,以及中途推翻重做的一版设计。 先看为什么这
压测卡在 400 QPS 上不去 知识库问答系统三月中旬做上线前压测,目标 800 QPS,结果压到 400 就开始大量超时。看 Grafana 面板,网关 CPU 才 40%,数据库连接池很闲,但整体 P99 已经飙到 3.2s。 拿 async-profiler 抓了 60 秒火焰图,TIME_
客服机器人上线两周,P95 首字延迟 4.2 秒 9 月初,我们给内部工单系统做的智能客服上了线。第三天开始收到投诉:"问一句话要等四五秒才出字"。我拉了 Grafana 看,数据比投诉描述的还难看: gateway_request_duration_seconds{quantile="0.95",
同事的问题:我加了 @Cacheable,为什么没生效 上周三下午,组里的小杨问我:"我在方法上加了 @Cacheable,压了 100 次,数据库慢查询日志里还是 100 条,Redis 里也看不到 key,是不是缓存没配好?" 我过去看了一眼他的代码: @Service public class
六月十三号上午,MySQL 被 3 万 QPS 打挂了 那天早上 9:07,我还在地铁上,DBA 的电话就打过来了:"你们的库 CPU 100%,连接数打满,赶紧看看是不是缓存挂了。" 到公司一看监控,数据库 QPS 从平时的 800 飙到 31000,CPU 100%,连接数 500 打满,大量请
运营说:我明明改了数据,页面还是旧的 去年做后台管理系统时遇到件怪事。运营在页面上改了一条商品记录的库存,保存成功,数据库里确认已经改了,但刷新列表看到的还是旧值。过几分钟再刷又对了。 我把日志级别调到 DEBUG,看到这么一段: ==> Preparing: SELECT id, name, s