aicanyin
午饭高峰，取餐台挤着二十多人，旁边柜台的“智能AI点餐屏”页面卡在王师傅的牛肉面订单上，一动不动。店员一边安抚顾客一边拿对讲机喊：系统又卡了，先别下单。
这个画面，做餐饮技术的朋友应该熟。餐饮AI应用的高并发处理能力，平时看着能跑，一到饭点就原形毕露。所以今天想聊聊到底怎么测，才能避免这种让人焦头烂额的宕机现场。
先搞清楚：你的系统要扛多大的并发量？
很多人一听“高并发”，就想到淘宝双11的千万级QPS。但餐饮AI属于“脉冲式”流量。一个连锁品牌如果有50家直营门店参与抖音团购，某个周五晚上放券，抢购瞬间可能涌进上万条请求；再比如午市11点半到12点半之间，单店的AI点餐请求往往会集中在三五分钟里冒出来。
有个数字可以做背景参考：国家统计局发布的数据显示，2023年全国餐饮收入达到5.28万亿元，同比增长20.4%。这么大的盘子，意味着点餐、AI客服、预点单系统背后的请求量并不小，但它不是均匀地压过来，而是像潮水一样一波一波地涌来。
所以靠前步不是开压测工具，而是和产品经理一起搞清楚业务高峰在哪、峰值有多少、会持续多久。如果上来就把目标定成“要抗住1小时内一万笔订单”，这个模型本身可能就是错的。
别急着上JMeter，先建好你的流量模型
做过压测的人都懂一个道理：测试只是执行，模型才是灵魂。流量模型里需要包含场景比例、用户思考时间、并发数、数据量。餐饮AI的场景不是用户点一下“购买”就结束，往往要经历“扫码—选店—浏览菜单—AI推荐聊天—加购物车—下单—支付—取餐”这一长串操作。
这里建议用分段流量模型：把AI对话、点餐查询、订单提交这三个最重的接口分开压。AI对话推荐通常调用大模型，响应是流式的；查询菜品接口短连接但频率高；订单提交是写入操作，对数据库压力最大。混在一起压，结果会失真。
压测工具怎么挑？别迷信“大而全”
压测工具市面上能排出一串：老牌JMeter，功能全但配置重；Locust用Python写脚本，方便改用户行为；k6轻量，还能和CI流程结合；wrk这类单机奇兵，适合快速压单一接口。
我个人更推荐团队用k6或者Locust。原因很简单：脚本代码化，可以进版本库，换台电脑就能复现，而不是在JMeter里保存一个别人找不到的.jmx文件。
如果只是压一个普通接口，先试wrk，十多行命令就能拿到数据。但别拿wrk去压AI流式接口——它不太擅长处理WebSocket/SSE那套长连接。
最容易翻车的三个细节，餐饮AI特别典型
我见过不止一个团队压测时全绿，上线后却被流量打垮，问题基本都出在下面几个细节上。
靠前，AI接口是流式响应。很多测试脚本按照普通POST请求写，等拿到完整响应就算结束。但AI点餐推荐是一边生成一边输出，用户的“首字时间”往往比“整体响应时间”更重要。压测时必须模拟客户端在流式传输中保持连接不断开，同时统计首包延迟。
第二，别把业务和AI放一个池子里压。业务请求大量走数据库，AI推理大量走GPU。两者同时压，CPU和内存会先爆掉，你很难判断瓶颈到底是数据库慢还是模型推理慢。正确做法是先分开压，再按生产比例做混合压测。
第三，别忘了测“扛不住时怎么办”。几乎所有系统都有限流和降级，但不少人根本没把这条链路算进压测范围。高峰期系统开始限流后，用户会看到“当前排队人数较多”，这其实是保护机制。你要压出的是：触发限流之后，还在队列里的请求能不能不被中断，订单会不会丢。否则，“保护”也会变成“事故”。
测试报告怎么看？别只盯平均值
压测结束，你会看到一堆指标。建议盯住P95响应时间（95%的请求在多少毫秒内完成）、错误率、吞吐量，以及服务端的资源水位。举个简单的例子：一个AI点餐接口平均响应时间200ms，但P99跑到4秒，说明忙起来的时候体验依然很糟。
软件工程前辈Fred Brooks在《人月神话》里说过一句话，我觉得特别适合印在测试团队墙上：测试只能证明系统存在错误，不能证明没有错误。压测的价值从来不是拍胸脯说“我们没问题”，而是把可能的坑提前暴露出来。
最后给一个能在今天就去做的建议：截取过去一个月线上最忙时段——比如某个周五午市——的真实请求日志，做一次流量回放压测，然后拿着报告去优化系统。不用追求“峰值跑满每一个点”。餐饮AI需要的是在高峰来临时，用户还能顺顺当当点上一碗牛肉面。
