Laravel Horizon in Produktion — Worker dimensionieren, Redis überleben, und die Retry-Strategie
6. Mai 2026 · 1 Min. Lesezeit · von Sudhanshu K.
Horizon macht Laravel-Queues lesbar. Das Dashboard ist großartig, das Supervisor-Modell ist tatsächlich nützlich, und die Failover-Story ist korrekt. Was es nicht macht, ist Ihre Worker-Dimensionierung, Queue-Isolations-Strategie oder Retry-Policy zu entscheiden — das bleiben Ihre Probleme, und die Defaults sind so konservativ, dass sie echte Produktionsprobleme verdecken.
Dies ist die Horizon-Konfig, die wir auf jeder gemanagten Laravel-Installation mit nennenswerter Hintergrundarbeit ausliefern.
Eine Produktions-Supervisor-Konfig
'environments' => [
'production' => [
'supervisor-default' => [
'connection' => 'redis',
'queue' => ['critical', 'default'],
'balance' => 'auto',
'minProcesses' => 4,
'maxProcesses' => 20,
'balanceMaxShift' => 2,
'balanceCooldown' => 3,
'tries' => 5,
'timeout' => 60,
],
'supervisor-long' => [
'connection' => 'redis',
'queue' => ['long-running'],
'balance' => 'simple',
'maxProcesses' => 4,
'timeout' => 600,
],
],
],Zwei Supervisor: einer für kurze, hochpriore Jobs (balance auto, mehr Worker), einer für lang laufende Batch-Jobs (feste Worker, längeres Timeout, kein Balancing). Beide auf denselben Supervisor mit demselben Timeout zu legen, ist die häufigste Horizon-Fehlkonfiguration, die wir sehen.
Der vollständige Beitrag behandelt:
- Queue-Isolation — warum „default" nicht die einzige Queue sein sollte
balance: autovsbalance: simplevsbalance: false- Redis-Persistence (AOF every-second) und was passiert, wenn Redis neu startet
- Der Retry-Backoff-Helper und Idempotenz bei eingehenden Webhook-Handlern
- Memory-Leak-Erkennung —
--memory=128und das Worker-Recycle-Pattern - Hygiene des Failed-Jobs-Dashboards und die Alerts, die wir auf der failed_jobs-Tabelle verdrahten
Wir liefern diese Horizon-Konfig auf jedem gemanagten Laravel-Deployment aus.
Vollständiger Artikel verfügbar
Vollständigen Artikel lesen