Dauerhafte Prozesse: Queue-Worker, Horizon und dauerhaft laufende Befehle

Manche Anwendungen brauchen ein Programm, das nie endet: einen Worker, der die Warteschlange abarbeitet, sobald ein Job eintrifft, Horizon, einen Message-Consumer oder einen Bot. Ein Cron-Job startet, erledigt seine Arbeit und endet; ein dauerhafter Prozess läuft weiter und startet von selbst neu, wenn er ausfällt.

Sie sind in den Tarifen Avanza, Max und Elastic verfügbar:

In Inicia, Webmaster und in den Konten eines Multi-Account-Hostings gibt es keine dauerhaften Prozesse. Warteschlangen lassen sich trotzdem mit dem Scheduler oder einem Cron-Job abarbeiten, mit bis zu einer Minute Wartezeit: Das erklären wir in Laravel installieren und unter Cron-Jobs.

Welchen Typ Sie wählen

• Queue-Worker: führt php artisan queue:work mit den angegebenen Warteschlangen aus. Für Laravel-Jobs in der Datenbank oder in Redis, ohne Horizon.
• Horizon: führt php artisan horizon aus. Für Redis-Warteschlangen, die Horizon mit seinem Dashboard und seinen Metriken verwaltet.
• Persistentes Redis: Valkey 8, kompatibel mit Redis, für Warteschlangen, Sitzungen und Horizon. Wird im Paketmanager aktiviert.
• Eigener Befehl: eine Shell-Zeile. Für Symfony Messenger, Message-Consumer, Bots oder jedes Programm, das keine Verbindungen annimmt.

Fügen Sie bei Horizon nicht zusätzlich einen Queue-Worker für dieselben Warteschlangen hinzu: Horizon startet und verteilt seine eigenen Worker. Horizon braucht Warteschlangen in Redis, und dafür gibt es das persistente Redis: Es belegt einen der Prozesse des Tarifs.

Ein dauerhafter Prozess ist für Hintergrundaufgaben gedacht: Warteschlangen, Horizon, das persistente Redis, das über einen Socket verbunden wird, oder ein eigenes Skript. Er ist nicht für Server gedacht, die Verbindungen annehmen: Programme, die auf einem Port lauschen, etwa ein Node.js-Server, eine Python-Anwendung, Laravel Reverb oder ein anderer WebSocket-Server, unterstützen wir nicht. Für WebSockets in Laravel verwenden Sie einen Pusher-kompatiblen Dienst, wie in WebSockets in Laravel beschrieben; braucht Ihr Projekt einen eigenen Server, benötigen Sie einen VPS.

Einen Prozess anlegen

1. Öffnen Sie im Kundenbereich Hosting, wählen Sie Ihren Dienst und gehen Sie zu Tools > Prozesse.
2. Klicken Sie im Block Dauerhafte Prozesse auf Prozess hinzufügen und wählen Sie den Typ.
3. Geben Sie den Arbeitsordner an, relativ zu Ihrem Home-Verzeichnis und ohne /home/usuario. Wenn Sie mit Deploy+ deployen, ist es deploy/miapp/current, mit dem Namen Ihres Repositorys statt miapp; haben Sie die Anwendung manuell installiert, der Projektordner, zum Beispiel mi-proyecto. Bei einem eigenen Befehl ist er optional: Ohne Ordner startet er in Ihrem Home-Verzeichnis.
4. Wählen Sie beim Queue-Worker und bei Horizon die PHP-Version: ab 8.1. Der Prozess verwendet die Binärdatei dieser Version, zum Beispiel /opt/alt/php84/usr/bin/php für PHP 8.4, und nicht das php, das Sie im Terminal finden und das eine andere Version sein kann. Wählen Sie dieselbe wie Ihre Website und aktivieren Sie in dieser Version die Erweiterungen, die die Anwendung braucht, im PHP-Selector.
5. Speichern Sie. Der Prozess erscheint als Wird gestartet und wechselt in weniger als einer Minute auf Läuft.

Queue-Worker

Geben Sie die Warteschlangen durch Kommas getrennt in der Reihenfolge ihrer Priorität an: Mit high,default leert der Worker zuerst high. Ohne weitere Angabe verarbeitet er default mit der Verbindung aus QUEUE_CONNECTION in Ihrer .env. Das sind die Standardoptionen:

php artisan queue:work --queue=default --sleep=3 --tries=3 --max-time=3600 --memory=256

• --sleep=3: Ist die Warteschlange leer, wartet er 3 Sekunden, bevor er erneut nachsieht.
• --tries=3: drei Versuche pro Job, bevor er als fehlgeschlagen gilt. Fehlgeschlagene Jobs landen in failed_jobs; Sie sehen sie mit php artisan queue:failed und wiederholen sie mit php artisan queue:retry.
• --max-time=3600: Nach einer Stunde endet der Worker und startet innerhalb einer Sekunde neu. So gibt er Speicher frei und lädt neuen Code, auch wenn ihn niemand neu startet.
• --memory=256: Überschreitet er 256 MB, endet er nach dem laufenden Job und startet neu.

Für Warteschlangen mit hohem Volumen können Sie mehrere Worker für dieselben Warteschlangen anlegen, einen pro Prozess des Tarifs. Beginnen Sie mit einem und fügen Sie nur dann einen weiteren hinzu, wenn sich die Jobs stauen.

Eigener Befehl

Schreiben Sie eine einzige Zeile, so wie Sie sie im Terminal eingeben würden, mit absoluten Pfaden für PHP und für alles, was nicht im gewählten Ordner liegt. Zum Beispiel ein Consumer von Symfony Messenger:

/opt/alt/php84/usr/bin/php bin/console messenger:consume async --time-limit=3600 --memory-limit=256M

Ein eigener Befehl kann ein Python-Skript oder eines in einer anderen im Konto verfügbaren Sprache für eine Hintergrundaufgabe starten, offiziell unterstützen wir aber nur PHP-Anwendungen: Alles, was nicht PHP ist, betreiben Sie in eigener Verantwortung.

Das Programm muss im Vordergrund bleiben. Fügen Sie weder & noch nohup noch Optionen hinzu, die es in den Hintergrund schicken: Der Wächter würde es sofort enden sehen, es erneut starten, und am Ende stünde es auf Fehlerhaft mit mehreren verwaisten Kopien. Wie bei --max-time in Laravel ist es sinnvoll, dass das Programm sich von Zeit zu Zeit selbst beendet, um Speicher freizugeben: Es startet von selbst neu.

Wie er am Laufen bleibt

• Ein Wächter prüft jede Minute die Prozesse des Kontos und startet die ausgefallenen. Sie sehen ihn unter Ihren Cron-Jobs als Zeile, die auf # hostsuar-procesos endet: Bearbeiten oder löschen Sie sie nicht, sie wird über Prozesse verwaltet.
• Endet das Programm, durch --max-time, wegen des Speichers oder nach einem php artisan queue:restart, startet es innerhalb einer Sekunde neu. Bei jedem Start wechselt es erneut in den Ordner und lädt daher nach einem Neustart die zu diesem Zeitpunkt veröffentlichte Version.
• Fällt er 5-mal hintereinander direkt nach dem Start aus, bevor er 30 Sekunden erreicht, bleibt er auf Fehlerhaft und wird erst wieder versucht, wenn Sie ihn im Panel neu starten. Zwischen den Versuchen wartet er jedes Mal etwas länger, um die CPU des Kontos nicht an ein Programm zu verschwenden, das nicht starten kann.
• Er läuft mit dem Benutzer Ihres Kontos innerhalb dessen Ressourcen: CPU, Arbeitsspeicher und Prozessanzahl des Tarifs sind dieselben, die Ihre Websites nutzen. Erreicht das Konto das Speicherlimit, kann das System den Prozess beenden, und der Wächter startet ihn neu. Prüfen Sie den Verbrauch unter CPU- und Ressourcennutzung.

Status und Aktionen

• Läuft: Das Programm lebt seit einigen Sekunden, ohne auszufallen.
• Wird gestartet: Er ist angefordert und noch nicht als laufend erfasst, oder er ist gerade gestartet; der Wächter startet ihn in weniger als einer Minute.
• Erneuter Versuch: Er fällt direkt nach dem Start aus, und der Wächter startet ihn erneut. Fällt er 5-mal hintereinander aus, bleibt er auf Fehlerhaft. Den Grund finden Sie in seinem Protokoll.
• Gestoppt: Sie haben ihn gestoppt, und er startet nicht von selbst.
• Fehlerhaft: Er ist 5-mal hintereinander beim Start ausgefallen und wartet darauf, dass Sie ihn neu starten.

Bei jedem Prozess können Sie:

• Neu starten: stoppt und startet ihn sofort, auch wenn er auf Fehlerhaft stand.
• Stoppen und Starten: Gestoppt wird er nicht wieder gestartet, bleibt aber in der Liste und behält seine Konfiguration.
• Protokoll ansehen: die letzten Zeilen, die das Programm geschrieben hat, mit einer Zeile arranca bei jedem Start und einer Zeile terminó con el código N tras S s bei jedem Ende. Überschreitet das Protokoll 1 MB, wird es gekürzt und behält den neuesten Teil.
• Bearbeiten: Beim Speichern startet der Prozess mit den Änderungen neu.
• Löschen: stoppt ihn und entfernt ihn aus dem Konto.

In Laravel landen die Fehler der Jobs außerdem in storage/logs/laravel.log und die fehlgeschlagenen Jobs in failed_jobs.

Wenn ein Prozess auf „Fehlerhaft“ bleibt

Öffnen Sie sein Protokoll: Fast immer erklärt die letzte Zeile vor jedem terminó con el código die Ursache. Die häufigsten:

• „no existe la carpeta de trabajo“ (der Arbeitsordner existiert nicht): Der Ordner ist falsch. Denken Sie daran, dass er relativ zu Ihrem Home-Verzeichnis ist, ohne /home/usuario.
• Eine PHP-Erweiterung fehlt, etwa redis, oder bei Horizon pcntl und posix: Aktivieren Sie sie in der PHP-Version des Prozesses, die nicht die Ihrer Website sein muss.
• Die Anwendung verbindet sich nicht mit Redis: Die .env verweist auf ein Redis, das nicht aktiv ist, oder auf einen anderen Socket.
• Ein eigener Befehl, der in den Hintergrund geht oder sofort endet, weil er nichts zu tun hat.
• Ein Fehler beim Start der Anwendung, zum Beispiel nach einem Deployment mit einer fehlenden Abhängigkeit.

Beheben Sie die Ursache und klicken Sie auf Neu starten. Solange er auf Fehlerhaft steht, verbraucht er keine Ressourcen.

Deployments und dauerhafte Prozesse

Ein Worker lädt den Code beim Start und hält ihn im Speicher; er muss also neu starten, um eine neue Version zu verwenden.

• Mit Deploy+ müssen Sie nichts tun: Sobald ein Deployment abgeschlossen ist, und auch beim Zurückkehren zu einer früheren Version, startet es die dauerhaften Prozesse neu, deren Ordner das current dieser Anwendung oder ein Ordner darin ist. Jeder Worker beendet den laufenden Job und startet innerhalb einer Sekunde mit dem neuen Code neu, und das Protokoll des Deployments zeigt, in welchem Zustand jeder geblieben ist. Setzen Sie weder queue:restart noch horizon:terminate in das Skript: Es läuft, bevor die Version aktiviert wird, und der Worker würde mit der vorherigen neu starten. In der Übersicht des Repositorys in Deploy+ können Sie den Queue-Worker dieser Anwendung mit bereits eingetragenem Ordner hinzufügen.
• Wenn Sie anders veröffentlichen (Git manuell, FTP), klicken Sie danach beim Prozess auf Neu starten oder führen Sie php artisan queue:restart, php artisan horizon:terminate oder php bin/console messenger:stop-workers aus, sobald der neue Code an seinem Platz ist. Laravel benachrichtigt die Worker über seinen Cache: Befehl und Worker müssen denselben CACHE_STORE verwenden.

SSH, solange es Prozesse gibt

Solange das Konto dauerhafte Prozesse hat, auch gestoppte, bleibt der SSH-Zugang aktiviert und lässt sich nicht deaktivieren: Beim Abschalten würden alle Prozesse des Kontos beendet. Wenn Sie SSH deaktivieren möchten, löschen Sie zuerst die dauerhaften Prozesse. Die Prozesse brauchen keine Sitzung, die Sie öffnen.

Den Tarif wechseln

• Zu einem Tarif mit weniger Prozessen: Die neuesten, die nicht mehr hineinpassen, werden gestoppt, und der Speicher des persistenten Redis wird auf das Maximum des neuen Tarifs angepasst.
• Zu einem Tarif ohne dauerhafte Prozesse: Alle werden gestoppt und bleiben in der Liste, damit Sie sehen, was Sie hatten. Wenn Sie zu Avanza, Max oder Elastic zurückkehren, können Sie sie wieder starten.

Bereiten Sie die Anwendung vor einem Tarifwechsel darauf vor, ihre Warteschlangen ohne sie abzuarbeiten.