Horizon 不直接监控并发,仅显示处理中、等待中任务数及吞吐量趋势;实际并发需结合 Worker 配置、进程数与 Redis 状态判断。

Horizon 本身不直接“监控并发”,它展示的是当前正在处理的任务数(Processing)、等待中的任务数(Waiting)和吞吐量趋势——并发能力是否被压满,得靠你读这些数字并结合 Worker 配置来判断。
为什么 horizon:stats()->processing() 返回的值比预期低?
这个值只反映当前 Supervisor 下所有 Worker 正在执行的任务数量,不是系统级并发上限。常见干扰点:
-
config/horizon.php中environments配置里某环境的supervisors数量写少了,比如只配了'default' => ['balance' => 1],那最多只有 1 个 Supervisor 启动,即使你开了 10 个 Worker 也无效 - Redis 连接池耗尽或超时,导致 Worker 在拉取新任务前就卡住,
processing值会停滞甚至归零,但waiting持续上涨 - 任务里用了
sleep()、file_get_contents()等阻塞调用,Worker 被占住无法释放,表面看是“并发低”,实际是代码阻塞 - PHP-FPM 或 CLI 的
max_execution_time触发强制终止,Worker 异常退出后由 Master Supervisor 重启,造成短暂processing波动
如何确认当前实际并发 Worker 数量?
别只信 Horizon 页面右上角的 “Processes” 数字,它可能滞后或未刷新。最准的方式是查进程树和 Redis 状态:
- 执行
ps aux | grep 'horizon:work',数出真正运行中的php artisan horizon:work进程数(注意排除grep自身) - 检查 Redis 中 Supervisor 注册信息:
redis-cli HGETALL horizon:supervisors,每个 key 对应一个 Supervisor 实例,value 包含其启动时间、PID 和 worker 数量 - 确认
config/horizon.php中trim配置没误删活跃 Supervisor 记录,比如'recent' => 10太小,旧 Supervisor 信息被清掉,页面显示不全
队列积压时,怎么快速判断是并发不足还是任务太慢?
关键看三个指标的组合变化,而不是单看一个数:
Laravel Cloud(cloud.laravel.com)。此技能用于处理所有 Laravel Cloud 请求,包括搜索和读取数据。只要任务涉及 Laravel Cloud,即使用此技能。
-
waiting持续上升 +processing接近配置上限 → 并发瓶颈,该加 Supervisor 或 Worker -
waiting上升 +processing低位震荡(如总在 1~3)→ 任务执行慢或频繁失败,查failed数和日志里的App\Jobs\YourJob::handle()耗时 -
processing为 0 但waiting很高 → Worker 全挂了,先跑php artisan horizon:status看状态,再查horizon:supervisors是否为空 - 用
redis-cli LLEN queues:default对比 Horizon 显示的waiting,如果原生命令值大很多,说明horizon:snapshot没跑成功或延迟严重
Horizon 面板里 “Throughput” 图表不动?
吞吐量数据完全依赖 horizon:snapshot 命令写入,它不运行,图表就是静态的。最容易被忽略的点:
-
APP_ENV=production下,horizon:snapshot默认跳过执行——必须确保环境不是testing,且没在config/horizon.php里手动关掉enabled - 服务器 cron 没跑通
schedule:run,或者app/Console/Kernel.php里漏写了$schedule->command('horizon:snapshot')->everyMinute() - Redis 写入权限不足,
horizon:snapshot执行时静默失败,建议手动跑一次并加-v参数看详细输出:php artisan horizon:snapshot -v
真正卡住并发的,往往不是 Horizon 配置,而是 Redis 连接稳定性、任务内部阻塞、或 Supervisor 启动失败后没报错。每次调参前,先用 ps 和 redis-cli 确认底层进程和状态是否如你所想。










