WordPress-Hosting-Ressourcen prüfen: PHP-Worker, Arbeitsspeicher und Limits
PHP-Worker, memory_limit und Ausführungszeit bestimmen, wie viel Last Ihre WordPress-Website verkraftet. So lesen Sie die Grenzen Ihres Hostings aus, machen Engpässe messbar und erhöhen das Speicherlimit richtig.
Mit KI erstellt – redaktionelle Prüfung ausstehend
WerbelinksMit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Mehr dazu
Wenn eine WordPress-Website unter Last langsam wird, Seiten mit „Auf dieser Website ist ein kritischer Fehler aufgetreten“ abbrechen oder Uploads scheitern, liegt die Ursache oft nicht im Code, sondern an den Grenzen des Hostings: zu wenig PHP-Prozesse für gleichzeitige Besucher, ein zu knappes Speicherlimit oder zu kurze Laufzeiten. Diese Grenzen stehen selten auf der Tarifseite, lassen sich aber auslesen. Diese Anleitung zeigt, wie Sie die tatsächlichen Werte ermitteln, verstehen, welche Einstellung welche Wirkung hat, und mit einer einfachen Messung prüfen, ob Ihr Hosting für die Besucherzahl ausreicht. Alle Werte und Fehlermeldungen stammen aus einem Test im Labor.
Voraussetzungen
- WordPress: getestet mit WordPress 7.1.2. Der Website-Zustand existiert seit Version 5.2.
- PHP: mindestens 7.4, im Test lief PHP 8.4 als Apache-Modul.
- Zugriff: Backend-Konto mit der Rolle Administrator. Für Änderungen an der
wp-config.phpFTP oder SSH, für die Schritte mit WP-CLI SSH. - Hoster-Dokumentation: die Beschreibung Ihres Tarifs oder die Einstellungsseite im Kundenbereich, denn viele Grenzen legt allein der Hoster fest.
- Backup: eine aktuelle Sicherung von Dateien und Datenbank, bevor Sie
wp-config.phpoder.htaccessändern. Ein Tippfehler in einer dieser Dateien legt die Website sofort lahm.
Schritt 1: Aktuelle Grenzen im Website-Zustand ablesen
Öffnen Sie im Backend „Werkzeuge > Website-Zustand“ und wechseln Sie zum Reiter „Bericht“. Klappen Sie die Abschnitte „Server“ und „WordPress-Konstanten“ auf. Die für die Ressourcen wichtigen Zeilen:
| Anzeige im Bericht | Bedeutung | Wert im Labor |
|---|---|---|
| PHP-Arbeitsspeichergrenze (memory_limit) | Höchster Arbeitsspeicher, den ein einzelner PHP-Aufruf belegen darf | 128M |
| Maximale PHP-Ausführungszeit (max_execution_time) | Sekunden, nach denen PHP ein Skript abbricht | 30 |
| Maximale Dateigröße beim Upload (upload_max_filesize) | Größte Datei in der Mediathek | 2M |
| Maximale Größe der PHP-Post-Daten (post_max_size) | Größe eines gesamten Formularversands | 8M |
| Maximale PHP-Eingabe-Variablen (max_input_vars) | Anzahl der Felder pro Formular, wichtig für große Menüs | 1000 |
| WP_MEMORY_LIMIT | Speicherlimit, das WordPress im Frontend anfordert | 40M |
| WP_MAX_MEMORY_LIMIT | Speicherlimit für den Adminbereich und aufwendige Aufgaben | 256M |
Die Anzeige 40M bei WP_MEMORY_LIMIT wirkt knapp, ist aber harmlos. Der Quellcode in wp-includes/default-constants.php zeigt: WordPress setzt das PHP-Limit nur dann auf WP_MEMORY_LIMIT, wenn dieser Wert größer ist als das bestehende Limit. Mit 128M auf dem Server bleibt es also bei 128M.
Die Grenze bezieht sich auf einen einzelnen Aufruf. Ein Hosting mit 2 GB Arbeitsspeicher und memory_limit 128M erlaubt nicht einem Aufruf 2 GB, sondern teilt den Speicher auf alle gleichzeitig laufenden PHP-Prozesse auf.
Verifizieren: Sie haben die sieben Werte aus der Tabelle für Ihre Website notiert.
Schritt 2: Werte aus Sicht des Webservers prüfen
Wer mit WP-CLI arbeitet, sollte wissen: Die Kommandozeile nutzt oft eine eigene PHP-Konfiguration. Im Labor meldete WP-CLI max_execution_time 0 (unbegrenzt), der Webserver dagegen 30 Sekunden. Für Besucher zählt der Wert des Webservers. Wenn Sie die Angabe aus dem Website-Zustand gegenprüfen möchten, legen Sie vorübergehend eine Testdatei im WordPress-Verzeichnis an:
<?php
// limits-test.php: nach dem Test sofort löschen
header('Content-Type: text/plain');
echo 'sapi ', php_sapi_name(), "\n";
foreach (['memory_limit','max_execution_time','upload_max_filesize','post_max_size','max_input_vars'] as $k) {
echo $k, ' ', ini_get($k), "\n";
}
require __DIR__ . '/wp-load.php';
echo 'memory_limit nach WordPress ', ini_get('memory_limit'), "\n";
echo 'Spitzenverbrauch ', round(memory_get_peak_usage() / 1048576, 1), " MB\n";Rufen Sie https://www.example.de/limits-test.php auf. Im Labor lautete die Ausgabe:
sapi apache2handler
memory_limit 128M
max_execution_time 30
upload_max_filesize 2M
post_max_size 8M
max_input_vars 1000
memory_limit nach WordPress 128M
Spitzenverbrauch 6.6 MBDie Zeile sapi verrät, wie PHP läuft: apache2handler steht für das Apache-Modul, fpm-fcgi für PHP-FPM, das bei vielen Hostern Standard ist. Der Spitzenverbrauch einer einfachen Startseite lag im Labor bei 6,6 MB. Mit Seitenbaukästen, Shop- oder Übersetzungs-Plugins steigt er deutlich. Löschen Sie die Datei nach dem Test, denn sie verrät Angreifern Details über Ihren Server.
Verifizieren: Die Testdatei zeigt dieselben Werte wie der Website-Zustand und ist danach gelöscht. Ein erneuter Aufruf liefert den Status 404.
Schritt 3: PHP-Worker verstehen
Jeder Seitenaufruf, der nicht aus einem Cache kommt, belegt für seine Dauer einen PHP-Prozess. Hoster nennen diese Prozesse PHP-Worker oder PHP-Prozesse. Technisch entspricht das bei PHP-FPM der Einstellung pm.max_children, laut PHP-Handbuch die Grenze für gleichzeitig bediente Anfragen. Beim Apache-Modul übernimmt MaxRequestWorkers diese Rolle. Laut Apache-Dokumentation werden Anfragen über dieser Grenze in eine Warteschlange gestellt, bis ein Prozess frei wird.
Diese Warteschlange wurde im Labor sichtbar gemacht. Ein Testskript wartete 2 Sekunden und antwortete dann. Zehn gleichzeitige Aufrufe ergaben:
| Gleichzeitige Prozesse | Antwortzeiten der 10 Aufrufe (gerundet) | Letzte Antwort nach |
|---|---|---|
| 2 | 2, 2, 4, 4, 6, 6, 8, 8, 10, 10 Sekunden | 10 Sekunden |
| 150 (Standard im Image, begrenzt durch 2 CPU-Kerne) | 2 bis 5,8 Sekunden | 5,8 Sekunden |
Mit zwei Prozessen arbeitete der Server die Aufrufe paarweise ab, der zehnte Besucher wartete fünfmal so lange wie der erste. Genau so verhält sich ein Tarif mit zwei PHP-Workern, wenn mehrere Besucher gleichzeitig ungecachte Seiten anfordern: Warenkorb, Kasse, Suche, Formulare und der Adminbereich. Die zweite Zeile zeigt die andere Grenze: Mehr Prozesse helfen nur, solange genug CPU-Kerne da sind.
Wie viele Worker Ihr Tarif hat, steht in der Tarifbeschreibung oder im Kundenbereich. Fehlt die Angabe, fragen Sie den Support. Bei PHP-FPM auf eigenem Server zeigt die Statusseite (pm.status_path) den Zähler „max children reached“. Laut PHP-Handbuch ist er 1 oder größer, sobald die Grenze einmal erreicht wurde.
Verifizieren: Sie kennen die Anzahl der PHP-Worker Ihres Tarifs oder haben beim Hoster danach gefragt.
Schritt 4: Bedarf abschätzen
Die Worker-Zahl allein sagt wenig. Entscheidend ist, wie lange ein Aufruf dauert. Ein Worker, der eine Seite in 0,2 Sekunden erzeugt, schafft rechnerisch fünf Aufrufe pro Sekunde. Braucht die Seite 1 Sekunde, ist es nur einer. Deshalb ist die Messung der Antwortzeit aus der Anleitung WordPress schneller machen: Ladezeit messen und Engpässe finden die Grundlage jeder Abschätzung.
Für den Arbeitsspeicher gilt: Jeder Worker belegt Speicher. Im Labor belegten die Apache-Prozesse mit PHP jeweils etwa 43 bis 51 MB (Wert VmRSS). Bei eigenem Server können Sie grob rechnen: verfügbarer Arbeitsspeicher für PHP geteilt durch Speicher pro Prozess ergibt die Obergrenze an Workern. Mehr Worker als Arbeitsspeicher führt zum Auslagern oder dazu, dass das Betriebssystem Prozesse beendet, und das ist schlimmer als eine Warteschlange.
Für die Planung helfen drei Fragen: Wie viele Besucher sind zur Spitzenzeit gleichzeitig auf Seiten, die nicht aus dem Cache kommen? Wie lange dauert ein solcher Aufruf? Und laufen im Hintergrund Aufgaben wie Backups, Importe oder WP-Cron, die ebenfalls Worker belegen?
Verifizieren: Sie haben die Antwortzeit einer ungecachten Seite gemessen und können abschätzen, wie viele Aufrufe pro Sekunde Ihre Worker schaffen.
Schritt 5: Speicherlimit richtig erhöhen
Reicht der Speicher nicht, bricht WordPress mit „Auf dieser Website ist ein kritischer Fehler aufgetreten“ ab. Im Protokoll steht die eigentliche Meldung. Im Labor belegte ein Test-Plugin absichtlich 150 MB bei einem Limit von 128M:
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 157286432 bytes) in /var/www/html/wp-content/plugins/speicher-test.php on line 3Die Zahl 134217728 Byte entspricht 128 MB, die Datei nennt den Verursacher. Wie Sie das Protokoll aktivieren, beschreibt die Anleitung WordPress Debug-Modus aktivieren und Error-Logs analysieren. Erstellen Sie ein Backup und tragen Sie dann in der wp-config.php oberhalb der Zeile /* That's all, stop editing! Happy publishing. */ ein:
define( 'WP_MEMORY_LIMIT', '256M' );Mit WP-CLI geht das mit wp config set WP_MEMORY_LIMIT 256M. Im Labor lief der Test danach durch: belegt 153 MB bei memory_limit 256M. Das funktionierte sogar, als das Limit per .htaccess mit php_value memory_limit 64M auf 64M gesenkt war, weil WordPress den Wert zur Laufzeit wieder anhebt.
Anders, wenn der Hoster das Limit fest vorgibt. Im Labor wurde dazu in der Apache-Konfiguration php_admin_value memory_limit 128M gesetzt. Trotz WP_MEMORY_LIMIT 256M blieb es bei 128M und der kritische Fehler kam wieder. Die gleiche Direktive in der .htaccess führte zu einem Fehler 500, weil sie dort nicht erlaubt ist. In diesem Fall hilft nur die Einstellung im Kundenbereich des Hosters oder ein anderer Tarif.
Erhöhen Sie das Limit nicht vorsorglich auf sehr hohe Werte. Ein Plugin, das 500 MB belegt, ist fehlerhaft, und ein höheres Limit verdeckt das nur. Zudem darf jeder Worker dann mehr Speicher belegen.
Verifizieren: Im Website-Zustand steht bei WP_MEMORY_LIMIT der neue Wert, und die Seite mit dem vorherigen Speicherfehler lädt ohne Fehlermeldung.
Schritt 6: Grenzen im Blick behalten
Hosting-Grenzen ändern sich: Plugins kommen hinzu, Besucherzahlen steigen, der Hoster stellt Tarife um. Prüfen Sie den Bericht im Website-Zustand nach jedem größeren Update und nach Tarifwechseln, und halten Sie die Werte aus Schritt 1 in Ihrer Dokumentation fest. Achten Sie im Fehlerprotokoll auf wiederkehrende Meldungen zu Allowed memory size und Maximum execution time. Treten diese Meldungen häufiger auf, reicht der Tarif nicht mehr aus oder ein Plugin arbeitet fehlerhaft.
Solche Kontrollen gehören zur laufenden Pflege, genau wie Updates und Sicherungen. Wer diese Aufgaben nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung, wöchentliche Backups auf externen Speicher und beginnt mit einer einmaligen Analyse der Website.
Verifizieren: Ihre Dokumentation enthält die aktuellen Grenzwerte mit Datum, und das Fehlerprotokoll zeigt keine neuen Speicher- oder Zeitfehler.
Typische Fehler
Allowed memory size of 134217728 bytes exhausted: Ein Aufruf hat das Speicherlimit von 128 MB überschritten. Verursacher steht in der Meldung. Limit perWP_MEMORY_LIMITerhöhen, wenn der Hoster es zulässt, und das Plugin prüfen.WP_MEMORY_LIMITwirkt nicht: Der Hoster setzt das Limit mitphp_admin_valueoder in einer nicht änderbaren PHP-Konfiguration. Im Labor blieb das Limit dann bei 128M. Ändern Sie den Wert im Kundenbereich des Hosters.- Fehler 500 nach Änderung der
.htaccess:php_admin_valueist in der.htaccessnicht erlaubt,php_valuefunktioniert nur beim Apache-Modul, nicht bei PHP-FPM. Entfernen Sie die Zeile wieder. - WP-CLI zeigt andere Werte: Die Kommandozeile hat eine eigene PHP-Konfiguration. Im Labor war
max_execution_timedort 0 statt 30. Maßgeblich für Besucher sind Website-Zustand und Testdatei. - Testdatei vergessen:
limits-test.phpoderphpinfo()-Dateien verraten Serverdetails. Löschen Sie sie direkt nach dem Test. - Mehr Worker, aber keine Besserung: Die CPU ist der Engpass. Im Labor mit 2 Kernen brauchten 10 gleichzeitige Aufrufe trotz 150 erlaubter Prozesse bis zu 5,8 Sekunden.
Häufige Fragen
Wie viele PHP-Worker brauche ich?
Dafür gibt es keine feste Zahl. Sie hängt von der Zahl gleichzeitiger Aufrufe ohne Cache und von deren Dauer ab. Eine Visitenkarten-Website mit Seiten-Cache kommt mit wenigen Workern aus, ein Shop mit vielen gleichzeitigen Bestellungen braucht mehr. Messen Sie die Antwortzeit und vergleichen Sie sie mit den Spitzenzeiten Ihrer Besucher.
Was ist der Unterschied zwischen WP_MEMORY_LIMIT und WP_MAX_MEMORY_LIMIT?
WP_MEMORY_LIMIT gilt für normale Aufrufe, WP_MAX_MEMORY_LIMIT für den Adminbereich und aufwendige Aufgaben wie die Bildbearbeitung. Der Standard für den zweiten Wert ist 256M, sofern das PHP-Limit nicht höher liegt.
Hilft ein Seiten-Cache bei zu wenigen Workern?
Ja, für nicht angemeldete Besucher. Eine Seite aus dem Cache belegt keinen oder nur sehr kurz einen PHP-Prozess. Warenkorb, Kasse, Suche und das Backend profitieren davon aber nicht.
Testumfang
Wir haben das im Labor mit WordPress 7.1.2 in einer Docker-Umgebung mit 384 MB Arbeitsspeicher durchgespielt. Dabei haben wir die Warteschlange mit 2 und mit 150 Apache-Prozessen belastet und den Speicherfehler mit einem Test-Plugin ausgelöst.
PHP-FPM und dessen Statusseite haben wir nicht getestet, diese Angaben stammen aus dem PHP-Handbuch. Läuft Ihr Server mit FPM, probieren Sie die Schritte am besten zuerst auf einer Kopie aus.
Fazit
Die Grenzen Ihres Hostings sind messbar: Der Website-Zustand zeigt die PHP-Werte, eine Testdatei bestätigt sie aus Sicht des Webservers, und ein Lasttest mit wenigen Aufrufen macht die Worker-Warteschlange sichtbar. Erhöhen Sie Limits gezielt nach einer Fehlermeldung und nicht vorsorglich. Wer die regelmäßige Pflege rund um diese Kontrollen abgeben möchte, findet sie bei der WordPress-Wartung von Marcel Schönfelder.
