道闸慢半拍，先别急着换相机：把这条链路分开查

车已经停到入口，相机也抓到了车牌，杆却迟迟不抬。后台转圈，出口队伍越来越长。

第一反应常是换相机、换路由器，或者把问题归给“老系统”。

道闸慢，是一个结果。识别、上传、业务判断、控制执行，任何一段变慢，都可能把车辆留在门口。

要把钱花对地方，先把通行过程拆开。

01 同一个慢 可能发生在不同位置

先看现场设备何时生成识别结果，再看平台何时收到事件、何时完成规则判断、何时发出控制，以及道闸何时实际动作。

这些时间点能够帮助区分：是图像识别困难、传输延迟、平台排队，还是控制器与机械动作异常。

各设备时钟不一致会干扰判断。最好结合统一时钟、关联事件号和同一段现场录像分析，而不是简单相减几个截图时间。

先定位延迟所在环节，再决定查网络、软件还是设备。

02 HTTP 不等于轮询 轮询也不是唯一病因

轮询是定时询问有没有新数据的一种方式。间隔较长会增加等待，频率过高又可能带来无效请求。

但 HTTP 可以用于设备主动上报，也支持连接复用；系统还可能使用长轮询、WebSocket或消息协议。不能看到“HTTP”就断言架构落后。

同样，不能凭“延迟一秒还是五秒”判断具体协议。识别耗时、网络、服务器和页面刷新，都可能影响你看到的结果。

该测的是实现效果，而不是给某个协议贴标签。

03 主动上报有价值 但不会自动解决所有问题

设备产生事件后主动发送，可以减少等待轮询的时间；发布订阅也便于多个业务模块接收事件。

但平台慢查询、线程阻塞、消息积压和重复重试，仍可能拖慢处理。用了 MQTT，也不等于每条记录都完整入库，更不等于开闸动作不会重复。

可靠的实现还要考虑本地缓存、接收确认、业务去重和异常补偿。

尤其开闸这类控制指令，应有对象、权限、有效期与执行结果。历史指令不能在网络恢复后过期补执行。

04 怎样排查 才不只是换设备碰运气

先保留高峰和低峰日志，记录通道、事件、车辆等待情况，以及设备在线与重启状态。

再由维护人员核对链路错误、实际流量、服务资源、数据库响应和控制器日志。必要时在维护窗口对单个环节做对照测试。

“减少视频后不卡了”只能提示负载相关，不能直接证明路由器就是唯一故障点。

机械卡阻、防砸状态异常或限位问题，应由专业人员处理，不能为了追求快而绕开安全联锁。

对照测试用来验证假设；修复后还要回到相同负载场景复测。

05 采购时 请它证明高峰表现

要求说明测试条件：通道数、设备数、业务量、网络条件和统计口径。不要只看一次演示的最快结果。

同时确认高峰排队、平台故障和网络中断时的预案。性能与故障处理都清楚，现场才更容易维持秩序。

先问“慢在哪里”，再问“换什么”。这一步做对，比只比较相机参数更有用。

你遇到的卡顿，是抓拍慢、后台慢，还是指令发出后杆不动？描述清楚，排查就已经前进了一步。

— 鑫禾智城 —

关注鑫禾智城，把停车故障拆开讲，让现场排查有顺序。

参考：HTTP语义与连接说明。配图为 AI 场景插画与原创技术图，均仅作示意。