Oberflächliche Funktionslisten zeigen selten das ganze Bild, wenn du Managed WordPress Hosting für die Entwicklung evaluierst. Du musst verstehen, wie sich die PHP-Thread-Zuweisung auf die Bearbeitung gleichzeitiger Anfragen auswirkt, wie mehrere Caching-Schichten zusammenarbeiten, um die Datenbanklast zu verringern, und ob die Containerisierung unter realen Bedingungen tatsächlich Probleme verhindert.
In diesem Leitfaden wird die technische Architektur von Kinsta für die PHP-Thread-Verwaltung, das Multi-Layer-Caching und die Container-Isolierung erläutert. Außerdem gibt es Zitate von Nikola Djuric, einem Senior Support Engineer im Kinsta-Team, über die Feinheiten des PHP-Thread-Managements.
Beginnen wir damit, wie PHP die Anfragen bearbeitet.
PHP-Threads verstehen und warum sie für die WordPress-Leistung wichtig sind
PHP-Threads verarbeiten eingehende, nicht zwischengespeicherte Anfragen. Jeder Thread bearbeitet jeweils eine Anfrage. Die Anzahl der verfügbaren Threads wirkt sich also direkt darauf aus, wie viele Besucher deine Website gleichzeitig bedienen kann.
Wenn ein Besucher eine nicht zwischengespeicherte Seite lädt, ein Formular ausfüllt oder einen Artikel in den Warenkorb legt:
- Der Webserver empfängt die Anfrage und übergibt sie an PHP-FPM.
- PHP ordnet die Anfrage einem verfügbaren Thread zu.
- Dieser Thread führt den PHP-Code aus, holt Datenbankdaten ab und erzeugt dynamische Ausgaben.
- Sobald er fertig ist, wird der Thread wieder freigegeben.
Die meisten Menschen wissen nicht, dass eine nicht zwischengespeicherte Anfrage einen PHP-Thread verwendet und dass die Verarbeitungsgeschwindigkeit von der PHP- und MySQL-Antwortzeit abhängt.
Bei gecachten Anfragen wird dieser gesamte Prozess übersprungen (sie berühren PHP überhaupt nicht). Deshalb sind die Cache-Raten HIT der größte Faktor dafür, wie viele Threads du tatsächlich brauchst.
WooCommerce-Websites, Mitglieder-Dashboards, REST-API-Verkehr und Headless-Setups umgehen das Caching viel häufiger und verbrauchen daher schnell Threads.
Wenn deine durchschnittliche API-Antwort zum Beispiel 250 Millisekunden dauert, kann jeder Thread vier Anfragen pro Sekunde verarbeiten. Bei acht Threads beträgt dein theoretischer maximaler Durchsatz 32 Anfragen pro Sekunde. Das gilt allerdings nur, wenn jede Anfrage in genau 250 ms abgeschlossen wird.
Wie zeitgleicher Verkehr PHP-Threads verbraucht
Die Anzahl der Threads ist bei simultanem Datenverkehr am wichtigsten. Wenn deine Website vier Threads hat und sechs gleichzeitige, nicht zwischengespeicherte Anfragen erhält:
- Vier Anfragen beginnen sofort mit der Bearbeitung.
- Zwei warten auf einen freien Thread.
Wenn neuer Traffic schneller eintrifft, als Threads frei werden, wächst der Rückstau.
Langsame Datenbankabfragen verschlimmern dies noch. Ein Beispiel: Eine Datenbankabfrage, die 10 Sekunden dauert, sperrt einen Thread für die gesamte Dauer. Wenn du drei zeitgleiche Anfragen erhältst, die jeweils langsame Abfragen auslösen, hast du drei Threads für insgesamt 30 Sekunden beansprucht. Während dieser Zeit kümmern sich die verbleibenden Threads um den restlichen Datenverkehr.
Wenn du WooCommerce-Filter, Kontoseiten oder Checkout-Workflows hinzufügst, steigt der Thread-Druck noch weiter an.
Einfache Websites brauchen nur vier PHP-Threads. Bei E-Commerce ist alles unter sechs wegen des hohen Bypass-Cache-Verhältnisses niedrig.
Das Verhältnis zwischen Thread-Anzahl und Ausführungszeit
Ein grober Weg, um den Thread-Bedarf abzuschätzen:
Benötigte Threads ≈ (Ungecachte Anfragen pro Sekunde × Durchschnittliche Ausführungszeit)
Auf dieser Grundlage benötigt eine Website mit 10 nicht gecachten Anfragen pro Sekunde und einer durchschnittlichen Ausführungszeit von 0,5 Sekunden etwa fünf Threads, um die Last ohne Warteschlangen zu bewältigen.
Das erklärt, warum das einfache Hinzufügen von mehr Threads keine bessere Leistung garantiert. Wenn langsame Datenbankabfragen dazu führen, dass die durchschnittliche Ausführungszeit von 0,5 Sekunden auf zwei Sekunden ansteigt, vervierfachen sich deine Thread-Anforderungen.
Die Lösung ist eine schnellere Codeausführung. Durch die Optimierung von Abfragen, die Verringerung externer API-Aufrufe und die Implementierung eines geeigneten Objekt-Cachings können die Ausführungszeit und die Anzahl der benötigten Threads drastisch reduziert werden, um deinen Traffic zu bewältigen.
PHP-Thread-Zuweisung für alle Kinsta-Pläne
Kinsta weist PHP-Threads auf der Grundlage der CPU- und RAM-Ressourcen zu, die dem Container jeder Website zur Verfügung stehen (jede Kinsta-Website läuft in einem eigenen LXD-Container, sodass die Ressourcen isoliert sind).
Allgemeine Muster für alle Pläne:
- Einstiegsvariante: 2-4 Threads mit 256 MB pro Thread. Dies ist ideal für Blogs und Websites mit statischen Inhalten und hohen Cache-HIT-Raten.
- Mid-Tier: 6-8 Threads mit 256 MB pro Thread, wobei einige Agentur-Tarife den Speicher auf 512 MB pro Thread erhöhen.
- Upper-Tier: 10-16 Threads mit 512 MB pro Thread, geeignet für Websites mit hohem Datenverkehr oder komplexen Inhalten.
- Multisite: 8-14 Threads je nach Stufe.
Du kannst die Thread-Zuweisung in MyKinsta > Info > PHP-Leistung den Speicherpool oder die Anzahl der Threads je nach dem Verkehrsaufkommen auf deiner Website erhöhen.
Dank dieser Flexibilität kannst du PHP an deine tatsächliche Arbeitslast anpassen, anstatt dich auf Standardwerte zu verlassen.
Schätzung der PHP-Thread-Anforderungen für deine Website
Je nachdem, wie viel Traffic den Cache umgeht, benötigen verschiedene Website-Typen individuelle Thread-Zuweisungen:
- Websites mit statischem Inhalt. 2-4 Threads sind in der Regel ausreichend, da fast der gesamte Datenverkehr über den Cache abgewickelt wird.
- WooCommerce-Shops. Beginne mit 8-12 Threads, abhängig von der Größe des Katalogs, der Komplexität der Filterung und dem Checkout-Volumen.
- API-lastige oder Headless-Anwendungen. Schätze anhand der Ausführungszeit (z. B. 0,25s Anfragen = etwa 4 Anfragen pro Sekunde pro Thread).
- Mitgliederseiten und LMS-Plattformen. Eingeloggte Nutzer/innen umgehen das Caching vollständig, so dass sie sich ähnlich wie beim E-Commerce verhalten.
Die Analysefunktionen von MyKinsta helfen dir, deine aktuellen Thread-Nutzungsmuster zu erkennen.
Wenn du bei hohem Datenverkehr Warteschlangen oder Timeout-Fehler siehst, muss deine Thread-Zuweisung wahrscheinlich angepasst werden.
Was passiert, wenn du dein PHP-Thread-Limit überschreitest?
Die Thread-Erschöpfung folgt einem vorhersehbaren Muster:
Es gibt keine Warteschlange für Anfragen. Die Anzahl der PHP-Threads auf deiner Website bestimmt, wie viele nicht zwischengespeicherte Anfragen auf einmal bearbeitet werden können. Wenn eine Anfrage eingeht und kein Thread verfügbar ist, wartet sie darauf, dass ein Thread frei wird. Wenn das nicht schnell genug geschieht, bekommt man 502 oder 503 „Bad Gateway Timeout“-Fehler.
Typische Symptome:
- Anfragen stauen sich in der Warteschlange von NGINX/PHP-FPM, wenn alle Threads mit der Bearbeitung beschäftigt sind.
- Die Endnutzer/innen erleben zuerst Verzögerungen, wie z. B. sich drehende Lader, langsame Checkout-Schritte oder abgebrochene AJAX-Aufrufe.
- 502 oder 504 Fehler erscheinen, sobald die Warteschlange vollständig gefüllt ist.
- Die Wiederherstellung erfolgt in der Regel innerhalb von 30-120 Sekunden, nachdem die langsamen Funktionen beendet sind und der Cache „aufgewärmt“ ist.
Langsame Datenbankabfragen sind die häufigste Ursache.
Langsame Datenbankabfragen brauchen mehr Zeit, um von den PHP-Threads verarbeitet zu werden, und beeinträchtigen so in der Regel die Leistung der Website.
Externe API-Aufrufe verursachen ähnliche Probleme. Zahlungs-Gateways, Steuerberechnungsdienste und Versand-APIs blockieren häufig Threads während der Kaufabwicklung.
Um eine Thread-Erschöpfung zu diagnostizieren, müssen mehrere Datenquellen untersucht werden. Das APM-Tool von Kinsta verfolgt langsame Anfragen und identifiziert Engpässe, während langsame Abfrageprotokolle Probleme mit der Datenbankleistung aufzeigen. Die Nginx-Warteschlangen-Metriken zeigen Muster für den Rückstau von Anfragen, und das Verhältnis zwischen Cache HIT und MISS gibt Aufschluss darüber, ob dein Caching funktioniert.
Die Lösung besteht darin, die Ausführungszeit zu optimieren:
- Langsame Datenbankabfragen benötigen eine Indizierung, eine Abfrageoptimierung oder eine reduzierte Abfrageanzahl.
- Schwere Plugins müssen möglicherweise durch leichtere Alternativen ersetzt werden.
- Cron-Aufgaben sollten in die Randzeiten verlegt werden.
- Externe API-Aufrufe profitieren von Caching, Hintergrundverarbeitung oder Unterbrechungen.
Optimierungen sollten vor dem Hinzufügen weiterer Threads erfolgen. Eine Erhöhung der Anzahl der Threads hilft nur, wenn die durchschnittliche Ausführungszeit unter Kontrolle ist.
Die mehrschichtige Caching-Architektur von Kinsta
Caching reduziert die Häufigkeit, mit der Anfragen PHP erreichen. Kinsta verwendet drei Schichten:
- Das Edge-Caching bedient statische Inhalte von globalen Standorten in der Nähe der Besucher.
- Objekt-Caching mit Redis reduziert die Datenbanklast, indem Abfrageergebnisse im Speicher gespeichert werden.
- Das Kinsta CDN liefert statische Inhalte von verteilten Edge-Standorten aus.
Diese Schichten arbeiten zusammen, um die Anfragen, die deine PHP-Threads und deine Datenbank erreichen, zu minimieren.
Edge-Caching durch Cloudflare
Das globale Edge-Netzwerk von Cloudflare stellt zwischengespeicherte HTML-Seiten auf der Grundlage von Cache-Schlüsseln bereit:
- URL- und Abfrageparameter
- bestimmte Cookies
- Authentifizierungsstatus
- WooCommerce-Warenkorb/Session-Cookies
Dadurch wird verhindert, dass personalisierte Inhalte an die falschen Nutzer/innen gesendet werden.
Die Cache-Bypass-Regeln verhindern auch das Zwischenspeichern dynamischer Inhalte, die stets aktuell sein müssen, wie z. B. WordPress-Adminbereiche oder WooCommerce-Kassenseiten.
Der Leistungsunterschied bedeutet, dass Edge-Cache-Anfragen die PHP-Threads vollständig umgehen und deine WordPress-Installation nie erreichen. Eine Website, bei der 80 % der Anfragen über den Edge-Cache laufen, benötigt nur PHP-Threads für die restlichen 20 % des Datenverkehrs.
Objekt-Caching mit Redis
Kinsta bietet Redis als Add-on an und benötigt keine Plugins von Drittanbietern, die sicherstellen, dass Redis mit dem Objekt-Caching-System von WordPress funktioniert.
Redis speichert die Ergebnisse von Datenbankabfragen im Speicher, so dass der Server diese Abfragen nicht erneut ausführen muss.
Redis ist ein Leistungsmultiplikator für gut strukturierte Websites – kein Pflaster für umfangreiche Abfragen oder unindizierte Tabellen.
Redis hilft, wenn:
- Viele Nutzer die gleichen Daten laden (Beiträge, Produkte, Kategorien)
- WooCommerce-Shops Kategorie- oder Produktabfragen durchführen
- APIs wiederholen identische Abfragen
Redis beschleunigt jedoch nicht die inhärent langsame PHP-Logik, blockierende externe API-Aufrufe oder schlecht optimierte Schleifen.
Kinsta CDN für die globale Bereitstellung von Assets
Das Kinsta CDN stellt statische Inhalte von über 260 Standorten weltweit bereit. Dadurch werden die Latenzzeiten für internationale Besucher verringert und statische Inhalte nicht mehr von deinem Ursprungsserver geladen. Außerdem werden Bilder automatisch in das WebP-Format konvertiert, wenn die Browser dies unterstützen.
Die Cache-Kontroll-Header bestimmen, wie lange das CDN Assets speichert. Du kannst die Cache-Dauer für verschiedene Asset-Typen konfigurieren, je nachdem, wie häufig sie sich ändern. Core CSS zum Beispiel kann mit einer längeren Cache-Dauer leben. Die Cache-Löschung für beide Ebenen erfolgt über MyKinsta, entweder einzeln oder für beide.
Mit dem Kinsta CDN und dem Edge-Caching kannst du HTML-Seiten, dynamische Inhalte und statische Assets verwalten. Zusammen sorgen sie dafür, dass die meisten Anfragen deinen Ursprungsserver nie erreichen oder PHP-Threads verbrauchen.
Container-Isolierung: Lösung des Problems der „lauten Nachbarn“
Shared-Hosting-Umgebungen leiden oft darunter, wenn eine Website zu viele Ressourcen verbraucht. Kinsta vermeidet dies durch die LXD-Container-Isolierung, die jedem Nutzer ihren eigenen Container zuweist:
- eine eigene CPU
- eigener Arbeitsspeicher
- isoliertes Dateisystem
- unabhängiger Software-Stack
Andere Websites können deine Ressourcen nicht beanspruchen, und Probleme in einem Container können sich nicht auf andere auswirken.
Container laufen auf optimierter Compute-Hardware und sorgen so für eine stabile, vorhersehbare Leistung, auch bei Verkehrsspitzen.
Skalierung für den Bedarf deiner Website
Wenn deine Website dauerhaft mehr Ressourcen benötigt, als dein aktueller Plan vorsieht, hast du die Möglichkeit, innerhalb deines Containers vertikal zu skalieren.
Das PHP-Performance-Add-on bietet zum Beispiel zusätzliche Threads und Speicher für Websites, die mehr Rechenleistung benötigen.
Du kannst auch zu einem höheren Plan wechseln und so die zugewiesenen Ressourcen deines Containers, die Anzahl der Threads und den Speicherplatz pro Thread erhöhen. Dies eignet sich für Websites, die über die Kapazität ihres aktuellen Plans hinauswachsen könnten.
Entscheidend ist, dass du erkennst, ob du eine Optimierung oder zusätzliche Kapazität brauchst. Wenn deine Threads gesättigt sind, die CPU-Auslastung aber niedrig bleibt, liegt das Problem an langsamen Abfragen oder externen API-Aufrufen, nicht an der Thread-Anzahl. Wenn du die Anzahl der Threads erhöhst, ohne dich um die langsame Ausführung zu kümmern, warten einfach mehr Anfragen länger auf den Abschluss langsamer Prozesse.
Zusammenfassung
Die PHP-Thread-Verwaltung, das mehrschichtige Caching und die Isolierung von Containern spielen alle eine entscheidende Rolle für die Leistung von WordPress im großen Maßstab. Wenn du verstehst, wie Threads funktionieren und wie Caching die Last, die sie bewältigen, reduziert, kannst du den richtigen Plan wählen und deine Website effektiv optimieren.
Wenn du wissen willst, wie die Kinsta-Infrastruktur deine WordPress-Workloads bewältigt, kannst du dich noch heute über die Managed Hosting-Plattform von Kinsta informieren.
Joel ist Frontend-Entwickler und arbeitet bei Kinsta als Technical Editor. Er ist ein leidenschaftlicher Lehrer mit einer Vorliebe für Open Source und hat über 200 technische Artikel geschrieben, die sich hauptsächlich um JavaScript und seine Frameworks drehen.
