Blockierende Redis-Commands in Magento-Webprozessen vermeiden

1. Das synchrone PHP-FPM-Worker-Modell als Ausgangspunkt

PHP-FPM hält einen Pool von Worker-Prozessen vor, deren Anzahl über pm.max_children begrenzt ist. Jeder eingehende HTTP-Request wird genau einem freien Worker zugewiesen, der die Anfrage von Anfang bis Ende alleine bearbeitet und erst danach wieder für einen neuen Request zur Verfügung steht. Es gibt in diesem Modell keine kooperative Nebenläufigkeit innerhalb eines einzelnen Workers, wie sie etwa Node.js mit seiner Event-Loop bietet: Solange ein Worker mit einer Aufgabe beschäftigt ist, kann er in dieser Zeit keine andere Anfrage annehmen.

Diese Architektur ist für klassische, kurzlebige Request-Response-Zyklen gut geeignet, setzt aber voraus, dass jede einzelne Operation innerhalb eines Requests in absehbarer, kurzer Zeit abgeschlossen ist. Jede Operation, die länger dauert als erwartet oder im schlimmsten Fall gar nicht zurückkehrt, blockiert nicht nur den aktuellen Request, sondern reduziert effektiv die Gesamtkapazität des Worker-Pools für alle anderen gleichzeitigen Besucher.

2. Was BLPOP, BRPOP und Co. konkret bewirken

BLPOP und BRPOP sind die blockierenden Varianten der Listenbefehle LPOP und RPOP: Statt sofort mit einem leeren Ergebnis zurückzukehren, wenn die angegebene Liste leer ist, hält Redis die Verbindung offen und liefert das Ergebnis erst zurück, sobald ein anderer Client per LPUSH oder RPUSH ein neues Element einfügt, oder bis ein optionales Timeout erreicht ist. Ohne explizites Timeout, also mit dem Wert 0, wartet der Aufruf theoretisch unbegrenzt lange.

Aehnlich funktioniert XREAD BLOCK für Redis Streams sowie WAIT beim Warten auf Replikationsbestätigungen: Alle diese Commands sind bewusst dafür entworfen, dass der aufrufende Client so lange wartet, bis ein bestimmtes Ereignis eintritt. Genau dieses Warten ist in einem Message-Queue-Consumer als eigenständigem, langlebigem Prozess sinnvoll und beabsichtigt, in einem PHP-FPM-Webprozess dagegen fundamental fehl am Platz.

3. Das konkrete Risiko: Worker-Erschöpfung und Timeout-Kaskaden

Landet ein blockierender Aufruf versehentlich in einem Magento-Controller oder einer Observer-Klasse, etwa weil ein Entwickler eine eigene, einfache Queue-Logik direkt über Redis-Listenbefehle bauen wollte, blockiert dieser eine Request nicht nur sich selbst, sondern reduziert die verfügbare Worker-Kapazität für alle anderen Besucher. Bei einem knapp dimensionierten pm.max_children können bereits wenige gleichzeitige, blockierte Requests den gesamten Worker-Pool erschöpfen, sodass neue Anfragen mit HTTP 502 oder 504 vom vorgeschalteten Webserver abgewiesen werden.

Besonders tückisch ist, dass dieses Verhalten unter normaler Last unauffällig bleiben kann, solange die betroffene Warteschlange regelmäßig gefüllt wird, und erst unter besonderen Umständen, etwa wenn der produzierende Prozess kurzzeitig ausfällt, zu einer Kaskade aus hängenden Workern und darauf folgenden Timeouts führt, die sich nur schwer im Nachhinein aus Logs rekonstruieren lässt.

4. Wo blockierende Commands in Magento-nahem Code typischerweise landen

In produktivem Magento-Kerncode kommen blockierende Redis-Commands praktisch nicht vor, das Risiko entsteht fast ausschließlich durch eigenen, custom geschriebenen Code. Typische Fundorte sind selbst gebaute Job-Queues, die statt auf Magentos etabliertem Message-Queue-Framework mit RabbitMQ direkt auf Redis-Listen mit BLPOP aufsetzen, oder Integrationsmodule, die synchron auf ein externes Ereignis warten wollen, etwa eine Bestätigung eines Drittsystems, die über einen Redis-Pub/Sub-Kanal oder eine Liste signalisiert wird.

Auch scheinbar harmlose Debugging- oder Wartungsskripte, die versehentlich innerhalb eines regulären Controllers statt als separates CLI-Kommando ausgeführt werden, können betroffen sein, insbesondere wenn ein Entwickler sie ursprünglich für die Kommandozeile geschrieben hat, wo blockierendes Warten unproblematisch ist, und sie später unverändert in einen Webkontext übernommen wurden.

5. Alternative 1: Kurzes Non-Blocking-Polling statt Warten

Statt mit BLPOP auf ein Ereignis zu warten, kann ein Webprozess stattdessen den nicht-blockierenden Befehl LPOP mit einem sehr kurzen, expliziten Zeitbudget wiederholt aufrufen, wobei zwischen den Versuchen ein kurzer, kontrollierter Sleep-Aufruf mit definierter Obergrenze liegt. Das hält die maximale Blockierungszeit eines Requests strikt begrenzt und vorhersehbar, auch wenn kein Ergebnis verfügbar ist, im Gegensatz zu einem potenziell unbegrenzten BLPOP.

Diese Lösung eignet sich vor allem für Fälle, in denen tatsächlich innerhalb weniger hundert Millisekunden ein Ergebnis zu erwarten ist, etwa beim Warten auf eine sehr schnelle, asynchron nebenläufig laufende Hintergrundberechnung. Für länger dauernde Vorgänge ist Polling innerhalb eines Webrequests trotzdem die falsche Wahl, weil es weiterhin Worker-Kapazität unnötig bindet, nur eben mit einer klaren Obergrenze statt potenziell unbegrenzt.

<?php
declare(strict_types=1);

/**
 * Nicht-blockierendes Polling mit strikt begrenzter Gesamtwartezeit,
 * als sichere Alternative zu BLPOP in einem Webprozess.
 *
 * @param Redis $redis Verbundener phpredis-Client.
 * @param string $key Liste, aus der ein Element erwartet wird.
 * @param int $maxWaitMs Maximale Gesamtwartezeit in Millisekunden.
 * @return string|null Das Element oder null bei Ablauf der Wartezeit.
 */
function pollForResult(Redis $redis, string $key, int $maxWaitMs = 500): ?string
{
    $deadline = microtime(true) + ($maxWaitMs / 1000);

    while (microtime(true) < $deadline) {
        $value = $redis->lPop($key);
        if ($value !== false) {
            return $value;
        }
        usleep(20000); // 20ms zwischen den Versuchen
    }

    return null;
}

6. Alternative 2: Magentos eigenes Message-Queue-Framework nutzen

Für wirklich asynchrone Verarbeitung bringt Magento bereits ein vollständiges Message-Queue-Framework mit, das standardmäßig auf RabbitMQ aufsetzt und über queue.xml, communication.xml sowie eigene Consumer-Klassen deklarativ konfiguriert wird. Ein Webrequest publiziert dabei lediglich eine Nachricht über MessageQueue\PublisherInterface und kehrt sofort zurück, ohne auf die eigentliche Verarbeitung zu warten, während ein separater, langlebiger Consumer-Prozess die Nachricht unabhängig vom Webrequest verarbeitet.

Dieses Muster löst das Grundproblem sauber: Der Webprozess bleibt kurz und nicht-blockierend, während die eigentliche, potenziell langwierige Arbeit in einem dafür vorgesehenen, dauerhaft laufenden Prozess stattfindet, der ganz bewusst blockierend auf neue Nachrichten warten darf, weil er kein PHP-FPM-Worker ist und keine anderen Requests blockiert.

7. Abgrenzung zu Consumer-Prozessen außerhalb des Webprozesses

Consumer-Prozesse, die über bin/magento queue:consumers:start gestartet werden, laufen bewusst als eigenständige, langlebige Prozesse außerhalb des PHP-FPM-Pools, oft über einen Process-Supervisor wie supervisord dauerhaft am Leben gehalten. In diesem Kontext ist blockierendes Warten nicht nur unproblematisch, sondern sogar die effizienteste Lösung: Ein Consumer, der per BLPOP oder dem RabbitMQ-Äquivalent auf neue Nachrichten wartet, verbraucht in Wartephasen praktisch keine CPU-Zeit und reagiert trotzdem sofort, sobald eine neue Nachricht eintrifft.

Der entscheidende Unterschied ist also nicht der Befehl selbst, sondern der Prozesskontext, in dem er ausgeführt wird: Blockierendes Warten ist in einem dedizierten, langlebigen Worker-Prozess korrekt und effizient, in einem Request-gebundenen PHP-FPM-Worker dagegen ein direkter Weg zu Worker-Erschöpfung und Timeout-Problemen.

# Consumer-Prozess korrekt außerhalb des Webprozesses starten
bin/magento queue:consumers:start custom.consumer.name --max-messages=1000

# In supervisord dauerhaft am Leben halten (Auszug supervisord.conf)
# [program:magento-consumer]
# command=bin/magento queue:consumers:start custom.consumer.name
# autorestart=true
# numprocs=2

8. Blockierende Aufrufe im Code-Review zuverlässig erkennen

Weil blockierende Commands unter normaler Last oft unauffällig bleiben, ist ein gezielter Blick im Code-Review sinnvoller als sich auf reaktives Monitoring im Produktivbetrieb zu verlassen. Eine einfache, aber wirksame Maßnahme ist eine statische Suche nach den Befehlsnamen BLPOP, BRPOP, BLMOVE und XREAD BLOCK im gesamten Codebestand, kombiniert mit einer manuellen Prüfung, ob der jeweilige Aufruf innerhalb eines Web-Controllers, Plugins oder Observers oder innerhalb eines eigenständigen CLI-Kommandos beziehungsweise Consumers liegt.

Ergänzend hilft eine klare Team-Konvention, die blockierende Redis-Aufrufe ausschließlich in explizit als Long-Running-Prozess gekennzeichneten Klassen erlaubt, etwa in einem eigenen Namespace für Consumer- und Worker-Code, wodurch ein versehentlicher Einsatz in regulärem Controller-Code bereits beim Code-Review auffällt, statt erst im Produktivbetrieb als Vorfall sichtbar zu werden.

9. Timeouts als letzte Absicherung, nicht als primäre Lösung

Selbst wenn ein blockierender Aufruf in einem Webprozess aus gutem Grund unvermeidbar erscheint, sollte niemals ein Timeout von 0 verwendet werden. Ein explizites, kurzes Timeout begrenzt zumindest den maximalen Schaden eines einzelnen blockierten Requests, ersetzt aber nicht die grundsätzliche architektonische Entscheidung, echte asynchrone Verarbeitung über das Message-Queue-Framework statt über direkte blockierende Redis-Aufrufe im Webprozess umzusetzen.

Zusätzlich sollte der PHP-FPM-eigene request_terminate_timeout als globale Notbremse konfiguriert sein, die einen hängenden Worker nach einer definierten Obergrenze zwangsweise beendet, selbst wenn ein einzelner blockierender Aufruf durch ein Versehen im Code doch produktiv landet.

10. Zusammenfassung

11. FAQ: Blockierende Redis-Commands in Magento: Das Wichtigste auf einen Blick