大促前的 WCS 压力测试：拿历史波次跑满负荷的实战清单

大促前一个月是我一年最忙的时候，不忙装设备，忙着一家家问：WCS 压力测试做了吗？十个里有八个回答"测过了"，再一问怎么测的——"拿平时波次跑了一遍，挺顺的"。我每次听到都想摘下安全帽：平时波次才几成负荷？拿慢跑的成绩去赌百米决赛？

WCS 压力测试原理不复杂，但九成仓都做错了，今天把清单摊开讲。

先说清楚：WCS 压力测试到底在压什么

一句话解释：WCS（仓储执行系统）是自动化设备的总指挥。WMS 说"这批订单要发"，WCS 负责翻译成机器听得懂的话：哪条线启动、哪个格口分货、哪台提升机去几楼。PLC 是前线班长，WCS 是团部。

所以压力测试压的，从来不是 WCS 服务器的 CPU 用了多少——那玩意儿平时也就 20%～30%，压满了也不说明啥。这就像去医院体检，光量了体重就说身体没问题，纯属自欺欺人。真正要压的，是这三条线：

第一，WCS 和 WMS 之间的消息通道。大促时订单像开闸放水，WMS 一秒钟甩过来几百条任务，WCS 的消息队列要是消化不良，任务就排队，现场设备空转等指令。你可以理解为：团部电话被打爆，前线只能干等。

第二，PLC 的扫描周期。PLC 按固定节拍循环干活：读信号、算逻辑、发指令，一圈叫一个扫描周期，正常几毫秒到十几毫秒。满负荷时信号量暴涨，周期被拉长，设备动作就"慢半拍"，输送线箱子间距一乱，堵包就是这么来的。

第三，网络抖动。WCS、PLC、扫码器、HMI 屏全挂在一张工业网上，平时风平浪静，大促时数据洪流一来，交换机端口一满，丢包、重传、延迟全来了。最气人的是这种故障平时一次不出现，压测不到位你永远发现不了。

三条线任何一条先垮，现象都一样：现场堵了。但病根不同、治法不同，所以压测不能只看"跑得顺不顺"，得把每条线的数据单独拎出来看。

拿历史波次当考题：这份清单照着打勾就行

压测用什么数据？我的答案一直没变：拿去年大促的真实历史波次，原样重放。造数据的人总会下意识把数据造得"合理"，而大促的真实数据从不合理——三个爆款 SKU 挤在同一个格口、退货波次撞上发货波次、某库区突然断货导致任务重排。真实波次里藏着的妖蛾子，是你编不出来的。

具体打法分五步：

第一步，定目标负荷。取去年大促单小时最高波次量乘以 1.2。为什么是 1.2？业务每年都说"今年增长 20%"，不管真假先按这个留余量。连 1.2 倍都吃不下的系统，大促当晚必出事。

第二步，搭压测环境。必须跟生产隔离，但 WCS、PLC 程序、网络拓扑跟生产一模一样。在生产环境"趁没单"压是大忌——压测要的是"满负荷"，生产环境你根本不敢放开跑。

第三步，重放历史波次。用 WMS 历史数据接口，把去年大促那几天的波次按时间压缩重放。波峰波谷、SKU 集中度、异常单比例，一个都别"美化"。

第四步，盯三组数。WCS 侧看消息队列深度和下发延迟；PLC 侧看扫描周期最大值；网络侧看端口利用率和丢包率。只看"堵没堵"，等于体检只量体重。

第五步，跑够时长。至少连续 4 小时满负荷。很多毛病是"慢性"的：内存泄漏、电机热保护、皮带跑偏，两小时后才露头。跑半小时就收工的叫"彩排"，不叫压测。

说两个真事。

2024 年 11 月，华东一家服饰电商仓，双 11 前做了"压测"——拿平时 7 成负荷的波次跑了 1 小时，报告很漂亮。双 11 凌晨 1 点，输送线主干道堵包：PLC 扫描周期被拉长，分拣信号慢了半拍，箱子追尾。现场 40 多号人改人工分拣，折腾到早上 6 点。据该仓自己复盘，那一晚的损失够做 20 次正经压测。

反例是 2025 年 8 月，美西一家 3PL 仓备战黑五。负责人拿去年黑五的历史波次，压到 1.2 倍，连跑 6 小时。第 4 小时暴露真问题：分拣机格口分配算法在满负荷下退化——平时 SKU 分散，算法游刃有余；大促爆款一集中，算法把大量箱子往同一个格口堆，满了才报警。平时 7 成负荷永远测不出这个毛病，因为算法退化的拐点恰好在 9 成负荷附近。他们花两周重写了分配权重，黑五当晚零事故。负责人说那是他那年花得最值的两周。

压测合格线：这几条红线过了就别上线

判分标准来了。下面这张表是"生死线"，踩中一条红线，当晚就别想睡安稳觉：

看出来了吗？标准定得很"不讲情面"。有人跟我说"堵一次包很正常，大促时人工清一下就行"。我直接开炮：大促当晚的人手是按正常波次排的，满负荷时让人去清堵，等于让消防员到火灾现场再去找水管——计划里就没这个人。

坑我都替你踩过了：压测最容易翻车的三个地方

第一个坑：压测环境跟生产"差不多"。差一个固件版本、少一台交换机，测出来的结果全是安慰剂。我见过最离谱的一次，压测环境的 WCS 是三个月前备份的老版本，测完皆大欢喜，上线当晚新版本改了一个消息队列超时参数，直接翻车。压测前第一件事：把生产环境的版本号一个个抄下来，对着抄。

第二个坑：只压设备，不压人。WCS 报警、HMI 弹框、异常处理流程，大促当晚是要靠人去点的。压测时故意制造几次异常——拔掉一个扫码器、模拟一个格口满——看看值班的人能不能在 5 分钟内按预案处理。设备是铁打的，人是会懵的，大促凌晨 3 点那个值班小伙，可能是入职才两个月的新人。

第三个坑最反常识：压得最狠的环节，往往不是最先坏的。WCS 是软件，压力下要么慢、要么报错，行为相对"诚实"。真正阴险的是上下游的"老实人"：PLC、扫码器、交换机。扫码器高速下识读率从 99.9% 掉到 97%，看着只差 3 个点，乘以大促单量就是灾难；交换机端口到 90% 利用率，平时不丢包，突发流量一冲就开始丢。所以我的取舍建议是：压测火力七成打在接口和边界上，三成留给 WCS 本体。别把压测做成 WCS 性能跑分大赛，那是供应商销售爱干的事，对你过好大促没用。

要不要压到设备物理极限？我的答案：压到 1.2 倍业务峰值就收。输送线电机长期满载跑，MTBF（平均无故障时间）是会打折的，你为了测一次极限把设备寿命提前消耗掉，这叫捡芝麻。大促真正的敌人从来不是"绝对峰值"那几分钟，而是"持续高位"那几小时——WCS 压力测试拼的是耐力，不是爆发力。

这钱花得值不值，看这一个数

每次聊到压测，必有人问：搭环境、请人、停线配合，这得花多少钱？值吗？我给你一笔账（数字是假设，算法是真的）：

假设你家大促单小时 1 万单，毛利一小时 40 万。堵包 2 小时转人工，效率剩三成，1.4 万单没按时发出。延期退款、差评、平台罚款，再加一晚上加班费，一次事故烧掉大几十万，眼睛都不眨。

而一次正经压测的成本呢？隔离环境很多集成商送，加上两三个人一周工时，总共几万块。账算到这里结论就一句话：这钱花得值不值，看这一个数——去年大促你最高一小时发了多少单，乘以 1.2，你的系统吃不吃得下。吃得下，这就是全仓最便宜的保险；吃不下，你省下的每一分钱都是在给大促当晚的事故众筹。

大促前一个月别再问"要不要压测"，问自己：历史波次准备好了吗？1.2 倍的目标敢不敢写进报告？敢就去压，不敢现在改还来得及。

作者：大刘｜自动化工程师