PHP Workers verstehen: Was sie sind und wann sie zum Bottleneck werden

php workers sind eigenständige Prozesse, die PHP-Code ausführen und dadurch jede dynamische Anfrage einer Website abarbeiten. Erreichen zu viele ungecachte Anfragen gleichzeitig den Server, belegen die vorhandenen Worker alle Slots, es bildet sich eine Warteschlange und der Engpass führt zu langen Antwortzeiten, TTFB-Spitzen und Fehlern.

Zentrale Punkte

Die folgenden Kernaussagen fasse ich kompakt zusammen, damit du schnell die richtigen Entscheidungen für Performance und Kapazität triffst.

• Definition: PHP Workers verarbeiten Anfragen seriell, pro Worker immer nur eine Anfrage.
• Bottleneck: Zu wenige Worker erzeugen Warteschlangen, TTFB steigt und Timeouts drohen.
• Ressourcen: Worker benötigen CPU-Kerne; falsches Verhältnis verursacht Context Switching.
• Caching: Je mehr Hits aus dem Cache, desto weniger Worker-Last bei Trafficspitzen.
• Skalierung: Anzahl der Worker an Seitenprofil, Plugins und Interaktionen anpassen.

Was sind PHP Workers im Hosting-Kontext?

Ich verstehe PHP Workers als digitale Kellner, die jede dynamische Anfrage einzeln bedienen. Ein Worker liest das PHP-Skript, löst Datenbankabfragen aus und baut daraus das HTML für den Browser. Läuft eine Aufgabe, bleibt der Worker bis zum Abschluss gebunden und steht erst dann wieder zur Verfügung, parallel arbeitet er nicht. In WordPress übernehmen Worker zusätzlich wiederkehrende Aufgaben wie Cron-Jobs, E-Mail-Versand und Sicherheitschecks. Genau deshalb beeinflussen Anzahl und Qualität der Worker die wahrgenommene Geschwindigkeit einer Website massiv.

Wann und warum entsteht der Worker-Engpass?

Ein Engpass entsteht, sobald mehr ungecachte Anfragen gleichzeitig eintreffen, als Worker verfügbar sind. Jede weitere Anfrage landet dann in einer Warteschlange und wartet auf einen freien Slot. Das erhöht den Time To First Byte, verlängert Ladezeiten und kann Checkout-Prozesse abbrechen lassen. In Shops oder Mitgliederbereichen verschärfen personalisierte Inhalte die Lage, weil der Cache viele Antworten nicht liefern kann, was die Last direkt auf die Worker schiebt. In dieser Situation erziele ich mit sinnvollem Caching, optimierten Plugins und einer stimmigen Worker-zu-CPU-Relation den größten Effekt.

Symptome erkennen: Metriken und Logs richtig lesen

Ich schaue zuerst auf TTFB, denn steigende Werte deuten auf Warteschlangen hin. Fehler wie 504 Gateway Timeout entstehen, wenn Anfragen zu lange blockiert bleiben und hart abbrechen. Im Hosting-Panel erkenne ich Warteschlangen über hohe Prozesszahlen bei gleichzeitig niedriger Netzwerkauslastung, was typisch für blockierte Worker ist. Zugriffslogs zeigen dann viele gleichzeitige Requests auf nicht gecachte Pfade wie Warenkorb, Checkout oder persönliche Dashboards. Steigen gleichzeitig Response-Zeiten im Backend, blockieren meist schwere Admin-Aktionen einzelne Worker länger als nötig.

Wichtige Abgrenzung: Webserver vs. PHP-FPM

Ich trenne klar zwischen Webserver-Worker (z. B. NGINX/Apache) und PHP-FPM-Workern. Der Webserver kann dank Keep-Alive und HTTP/2 viele Verbindungen multiplexen und statische Assets extrem parallel bedienen. Die eigentliche Engstelle entsteht aber erst in PHP-FPM: Dort bearbeitet jeder Child-Prozess genau eine Anfrage. Selbst wenn der Browser dutzende Requests parallel öffnet, limitiert die Zahl der PHP-Prozesse die gleichzeitige Abarbeitung dynamischer Pfade. Diese Unterscheidung erklärt, warum Seiten mit vielen statischen Dateien schnell wirken, während einzelne, dynamische Endpunkte (Checkout, Login, REST-API) trotzdem stauen.

Optimale Worker-Anzahl: Rechenkerne, RAM und App-Profil

Die sinnvolle Worker-Zahl hängt vom Anteil dynamischer Seiten, der Plugin-Landschaft und den verfügbaren CPU-Kernen ab. Ich plane niemals deutlich mehr Worker als CPU-Kerne ein, weil permanentes Kontextwechseln die Latenz erhöht. Für kleine Blogs genügen meistens zwei bis vier Worker, während aktive Shops und LMS deutlich mehr benötigen. Entscheidend bleibt das Zusammenspiel: Mehr Worker ohne CPU-Reserven bringt keine Beschleunigung. Deshalb teste ich mit Last, messe TTFB und kontrolliere, ob die Queue verschwindet, bevor ich weiter aufrüste.

Szenario	Ungecacht	Worker	CPU-Kerne	Effekt	Aktion
Blog mit Cache	Sehr gering	2–4	2–4	Schnelle Auslieferung	Cache pflegen, Plugins schlank halten
WooCommerce mit Spitzen	Mittel–hoch	6–12	4–8	Kurze Wartezeiten	Checkout entlasten, Worker erhöhen
Mitglieder/LMS	Hoch	8–16	8–16	Weniger Timeouts	Personalisierung cachen, CPU nachziehen
API-lastige App	Hoch	8–20	8–20	Gleichmäßigere TTFB	Queries optimieren, Limits setzen

Faustregeln zur Dimensionierung

Für ein erstes Gefühl rechne ich mit der einfachen Näherung: benötigte Worker ≈ gleichzeitige ungecachte Requests. Diese Gleichzeitigkeit ergibt sich aus Anfragefrequenz mal mittlerer Bearbeitungszeit. Beispiel: 10 Requests/s mit 300 ms Servicezeit ergeben rund 3 gleichzeitige PHP-Requests. Plane ich Sicherheitsreserven und kurze Peaks ein, verdopple ich diesen Wert. Wichtig: Diese Zahl muss zu CPU-Kernen und RAM passen; ein Worker ohne CPU-Zeit ist nur ein weiterer Wartender.

Speicherbudget richtig kalkulieren

Jeder PHP-FPM-Prozess verbraucht RAM, abhängig von PHP-Version, aktivem Opcache und den geladenen Plugins. Ich messe den realen Footprint unter Last (ps/top) und multipliziere ihn mit pm.max_children, addiere Webserver, Datenbank und Cache-Dienste. So verhindere ich Swapping und den OOM-Killer. Als Regel halte ich 20–30% freien RAM-Puffer. Steigt der Verbrauch pro Prozess deutlich, deute ich das als Signal für Plugin-Diät, weniger Extensions oder restriktivere memory_limit-Settings pro Pool.

Caching als Entlastungsschicht

Je mehr ich aus dem Cache liefere, desto weniger Energie verbrauchen die Worker. Page-Cache, Objekt-Cache und Edge-Cache reduzieren die PHP-Ausführung drastisch. Dynamische Teile wie Warenkorb oder personalisierte Blöcke kapsle ich mit ESI oder Ajax, damit der Rest weiterhin gecacht bleibt. Wer tiefer einsteigen will, findet im Serverseitiges Caching Leitfaden hilfreiche Strategien zu NGINX und Apache, die Worker wirklich entlasten. So senke ich die TTFB spürbar und halte die Reaktionszeit unter Last niedrig.

Ich berücksichtige auch Cache-Invalidierung und Aufwärmstrategien: Nach Deployments oder großen Produktänderungen wärme ich kritische Seiten und API-Routen vor. In Shops lade ich Kategorieseiten, Bestseller, Startseite und Checkout-Preloads, um Kaltstart-Peaks abzufedern. Für Objekt-Cache achte ich auf saubere Schlüssel-Strategien, damit ich Hotsets nicht unnötig verwerfe.

Typische Irrtümer und teure Fallen

Viele vermuten zuerst fehlenden RAM oder CPU als Hauptproblem, obwohl die Queue der Workers der eigentliche Engpass ist. Ich prüfe deshalb, ob gecachte Seiten schnell bleiben und nur dynamische Pfade ausufern. Ein weiterer Irrtum ist „mehr Worker löst alles“, was ohne zusätzliche Kerne in hohe Kontextwechsel und schlechtere Latenz kippt. Ebenso binden schlechte Plugins einen Worker übermäßig lange, was die gefühlte Performance verschlechtert. Ich reduziere daher Add-ons, optimiere Datenbankabfragen und skaliere Ressourcen im Gleichklang.

WordPress-spezifische Hotspots

• admin-ajax.php und wp-json: Viele kleine Calls summieren sich und blockieren Worker; ich bündele Requests und setze sinnvolle Caches.
• Heartbeat API: Im Backend begrenze ich Frequenzen, damit nicht unnötig viele gleichzeitige Requests entstehen.
• WooCommerce wc-ajax: Warenkorb-, Versand- und Coupon-Checks sind oft uncached; ich reduziere externe API-Aufrufe und optimiere Hooks.
• Transients und Optionen: Überfüllte Autoload-Optionen oder teure Transient-Regenerationen verlängern die PHP-Laufzeit und damit die Slot-Bindung.

Praxis: Von drei auf acht Worker – ohne Stau

Angenommen, ein Shop betreibt nur drei Worker und erlebt abends Checkout-Staus. Ich analysiere zuerst Pfade, die nicht aus dem Cache kommen, und messe die TTFB unter Last. Dann aktiviere ich sauberes Page- und Objekt-Caching und lagere nur personalisierte Bereiche aus. Anschließend erhöhe ich die Worker auf acht und gebe gleichzeitig zwei zusätzliche CPU-Kerne frei. Im nächsten Lasttest sinken die Warteschlangen, und die Fehlerquote fällt deutlich.

Optional glätte ich Peaks zusätzlich, indem ich im Webserver konservative Limits für teure Endpunkte setze (z. B. geringe gleichzeitige Upstreams für Checkout), während ich statische und gecachte Inhalte unbegrenzt schnell ausliefere. Das nimmt Druck aus dem FPM-Pool und stabilisiert die TTFB in der Breite, selbst wenn einzelne Nutzeraktionen kurz langsamer sind.

Monitoring und Lasttests: Werkzeuge, die ich nutze

Ich verfolge TTFB, Antwortzeit und Fehlerquote in kurzen Intervallen, um Staus früh zu sehen. Für synthetische Last nutze ich Tools wie K6 oder Loader, weil sie realistische Peaks erzeugen. Application-Logs helfen, langsame Queries und externe API-Calls zu identifizieren, die Worker fesseln. Zusätzlich kontrolliere ich PHP-FPM-Statusseiten, um belegte, wartende und freie Slots im Blick zu behalten. Werden Slots dauerhaft voll, erhöhe ich Worker und CPU schrittweise und prüfe jeden Schritt mit Testlast.

Metriken sicher deuten

• max children reached: Die Obergrenze wurde erreicht; Anfragen warten – Zeit für mehr Worker oder schnelleres Caching.
• listen queue: Eine wachsende Queue bestätigt Stau vor FPM; ich prüfe Webserver- und Upstream-Settings.
• request_slowlog_timeout und Slowlog: Identifiziert genau die Request-Stellen, an denen Worker hängen.
• upstream_response_time in Webserver-Logs: Zeigt, wie lange PHP geantwortet hat; ich korreliere mit request_time und Statuscodes (502/504).

Konkrete Upgrade-Signale richtig deuten

Steigt die TTFB trotz aktivem Caching spürbar an, fehlt meistens Worker-Kapazität. Häufen sich 504-Fehler bei Aktionen wie Checkout oder Login, liegen echte Staus vor. Mehr gleichzeitige Bestellungen, spontane Kampagnen oder Launches rechtfertigen zusätzliche Worker, damit Transaktionen sauber durchlaufen. Tritt der Fehlerstatus 503 auf, lohnt der Blick in diese Anleitung zu WordPress 503 Fehler, weil fehlerhafte Prozesse und Limits ähnliche Effekte erzeugen. Danach entscheide ich, ob ich Worker, CPU oder Timeouts anhebe.

Konfiguration: PHP-FPM und sinnvolle Limits

Bei PHP-FPM bestimme ich mit pm.max_children die maximale Zahl gleichzeitiger Prozesse und damit die Obergrenze der Worker. Mit pm.start_servers und pm.min/max_spare_servers kontrolliere ich, wie schnell Kapazität bereitsteht. pm.max_requests schützt vor Memory-Leaks, indem Prozesse nach X Requests neu starten. request_terminate_timeout sichert lange Läufer ab, damit ein Worker nicht ewig hängen bleibt und Slots blockiert, was ich für Checkout-Pfade sorgfältig setze. Diese Stellschrauben wirken direkt auf Warteschlangen, daher ändere ich sie nur zusammen mit Tests.

Ich wähle den passenden pm-Modus bewusst: dynamic für schwankende Last, ondemand für sehr sporadische Last auf kleinen Instanzen und static für konstant hohe Spitzen, wenn CPU und RAM klar reserviert sind. Außerdem aktiviere ich Opcache mit ausreichendem Speicher und revalidiere Scripts effizient, damit Worker weniger CPU pro Request brauchen. Mit request_slowlog_timeout und slowlog finde ich Hotspots im Code, ohne den Pool zu vergrößern. Ich prüfe, ob der FPM-Socket als Unix-Socket oder TCP angebunden ist; lokal bevorzuge ich Sockets, über Container/Hosts oft TCP.

Checkliste für Shops, Memberships und LMS

Für Shops halte ich dynamische Seiten wie Warenkorb, Checkout und „Mein Konto“ schlank und reduziere externe Calls. In Mitgliederbereichen prüfe ich jede Profil- und Dashboard-Abfrage auf überflüssige Queries. Bei LMS setze ich auf Objekt-Cache für Kurslisten, während ich Fortschrittsanzeigen effizient rendere. In allen Fällen ziele ich auf wenige, kurze Requests pro Aktion, damit Worker schnell wieder frei sind. Erst wenn diese Hausaufgaben sitzen, erweitere ich Worker und CPU parallel.

Sessions, Locking und Concurrency-Fallen

Ich beachte Session-Locks, die in PHP standardmäßig pro Nutzer-Session seriell wirken. Laufen teure Aktionen (z. B. Payment-Callbacks) während derselben Session, blockiert das weitere Requests dieses Nutzers – die Folge sind Spitze in TTFB und gefühlte Hänger. Ich minimiere Session-Einsatz, lagere nur das Nötigste in Sessions, und stelle auf performante Handler (z. B. In-Memory) um. In WooCommerce achte ich auf Sessions und Transient-Stürme beim Warenkorb.

Datenbank und externe Dienste als Multiplier

Oft fesseln langsame SQL-Queries oder Rate-Limits externer APIs den Worker. Ich optimiere Indizes, reduziere N+1-Abfragen, setze Query-Caches (Objekt-Cache) und begrenze externe Calls mit Timeouts und Retry-Logik. Werden Zahlungs-, Versand- oder Lizenzserver träge, begrenze ich Parallelität auf diesen Routen bewusst, damit nicht der ganze Pool wartet. So bleiben freie Slots für andere Nutzeraktionen übrig.

Anbieterwahl und Hosting-Tuning mit Blick auf Worker

Ich bevorzuge Hosting-Pläne, bei denen ich PHP Workers flexibel einstellen und parallel CPU-Kerne erweitern kann. Leistungsfähige Anbieter liefern saubere Caching-Ebenen, schnelle NVMe-Storage und klare Metriken im Panel. Als Einstieg in die technische Bewertung hilft mir der PHP-Hosting Guide, der zentrale Kriterien und Optionen greifbar macht. Wichtig ist mir, dass Unterstützung bei Trafficspitzen nicht abreißt, sondern Kapazität ohne Reboot bereitsteht. So halte ich TTFB, Fehlerquote und Durchsatz in Balance.

Plan für Peaks und Schutz vor Bot-Last

Ich stimme im Vorfeld einen Eskalationspfad ab: Wie schnell lassen sich Worker und CPU erhöhen, wer überwacht, welche Timeouts dürfen temporär wachsen? Parallel minimiere ich Bot- und Spam-Last über sinnvolle Rate-Limits auf dynamischen Endpunkten. Jede abgewehrte unnötige Anfrage ist ein frei gebliebener Worker-Slot für echte Kunden.

Zum Mitnehmen

PHP Workers entscheiden, wie schnell dynamische Seiten unter Last reagieren, weil jeder Prozess nur eine Anfrage gleichzeitig abwickelt. Ich minimiere die Last mit konsequentem Caching, räume blockierende Plugins auf und stelle eine sinnvolle Worker-zu-CPU-Relation her. Unter Spitzen erhöhe ich Worker behutsam und teste, ob die Warteschlange verschwindet und die TTFB fällt. Logs, FPM-Status und Lasttests liefern mir die Belege, ob ich richtig skaliere oder Timeouts nachschärfen muss. Wer diese Hebel im Griff hat, vermeidet Engpässe, schützt Transaktionen und sorgt für ein spürbar schnelleres Nutzererlebnis.