PHP-OPcache und PHP-Einstellungen für WordPress messen und anpassen

Viele WordPress-Websites laufen mit PHP-Einstellungen, die niemand bewusst gewählt hat: 2 MB Upload-Grenze, 128 MB Arbeitsspeicher und ein OPcache mit Werkzeug-Standardwerten. Das fällt erst auf, wenn ein Import abbricht, ein Bild sich nicht hochladen lässt oder der Website-Zustand „Der Opcode-Cache ist nicht aktiviert“ meldet. Diese Anleitung zeigt, wie Sie die aktuellen Werte auslesen, OPcache sinnvoll dimensionieren und die wichtigsten PHP-Grenzen an der richtigen Stelle anheben. Alle Befehle und Einstellungen wurden im Labor mit WordPress 7.1.2 und PHP 8.4.26 unter Apache geprüft, inklusive der typischen Fehler.

Voraussetzungen

• WordPress: eine aktuelle Installation, im Labor WordPress 7.1.2 in deutscher Sprache.
• PHP: PHP 8.x, im Labor PHP 8.4.26. Die Mindestempfehlung von WordPress liegt laut Versions-API bei PHP 7.4. Ein Wechsel der PHP-Version ist ein eigenes Thema, siehe PHP-Version für WordPress aktualisieren.
• Zugriff: Rolle Administrator im Backend. Für OPcache-Werte zusätzlich Root- oder SSH-Zugriff auf den Server bzw. ein PHP-Menü im Hosting-Kundenbereich. Für .user.ini oder .htaccess reicht SFTP.
• Backup: eine aktuelle Sicherung von Dateien und Datenbank. Eine fehlerhafte Zeile in der .htaccess führt sofort zu Serverfehler 500.
• Ressourcen: freier Arbeitsspeicher auf dem Server. OPcache reserviert seinen Speicher einmal pro PHP-Pool, memory_limit gilt dagegen pro gleichzeitigem Aufruf. Auf kleinen Servern mit 1 bis 2 GB RAM rechnen Sie beides vorher durch.

Schritt 1: Aktuelle Werte im Website-Zustand ablesen

Öffnen Sie im Backend Werkzeuge > Website-Zustand. Im Reiter Status taucht bei deaktiviertem Cache die Empfehlung „Der Opcode-Cache ist nicht aktiviert“ mit dem Kennzeichen „Leistung“ auf. Der Reiter Information listet im Bereich Server die Werte, mit denen PHP Ihre Website tatsächlich ausführt, unter anderem:

Anzeige im Website-Zustand	PHP-Einstellung	Standard im Labor-Image
PHP-Arbeitsspeichergrenze (memory_limit)	memory_limit	128M
Maximale Dateigröße beim Upload	upload_max_filesize	2M
Maximale Größe der PHP-Post-Daten	post_max_size	8M
Maximale PHP-Ausführungszeit	max_execution_time	30
Maximale PHP-Eingabe-Variablen	max_input_vars	1000
Opcode-Cache	opcache.enable	aktiviert

Im Bereich WordPress-Konstanten sehen Sie außerdem WP_MEMORY_LIMIT (Standard 40M) und WP_MAX_MEMORY_LIMIT (Standard 256M). Mit „Bericht in die Zwischenablage kopieren“ sichern Sie den Ausgangszustand zum Vergleich.

Wichtig: Lesen Sie diese Werte im Browser ab, nicht mit WP-CLI. Die Kommandozeile nutzt eine eigene PHP-Laufzeit (SAPI „cli“). Im Labor meldete wp eval für den Opcode-Cache „Durch die Konfiguration deaktiviert“ und eine Ausführungszeit von 0, obwohl der Webserver OPcache verwendete. Ursache ist opcache.enable_cli, das laut PHP-Handbuch standardmäßig auf 0 steht.

Verifizieren: Sie kennen die aktuellen Werte für Arbeitsspeicher, Upload, Post-Größe, Ausführungszeit und Eingabe-Variablen und haben den Bericht gespeichert.

Schritt 2: OPcache-Auslastung messen

OPcache speichert den kompilierten Bytecode aller PHP-Dateien im gemeinsamen Arbeitsspeicher. PHP muss die Dateien dann nicht bei jedem Aufruf neu einlesen und übersetzen. Ob der Cache groß genug ist, zeigt der Website-Zustand nicht. Legen Sie dafür vorübergehend ein Prüfskript mit zufälligem Namen im WordPress-Verzeichnis an, etwa oc-pruefung-7f3a.php:

<?php
$s = opcache_get_status(false);
echo 'aktiv: ', var_export($s['opcache_enabled'], true), PHP_EOL;
echo 'Speicher belegt: ', round($s['memory_usage']['used_memory'] / 1048576, 1), ' MB', PHP_EOL;
echo 'Speicher frei: ', round($s['memory_usage']['free_memory'] / 1048576, 1), ' MB', PHP_EOL;
echo 'Skripte im Cache: ', $s['opcache_statistics']['num_cached_scripts'], PHP_EOL;
echo 'Schlüssel maximal: ', $s['opcache_statistics']['max_cached_keys'], PHP_EOL;
echo 'Neustarts wegen Speichermangel: ', $s['opcache_statistics']['oom_restarts'], PHP_EOL;
echo 'Strings: ', round($s['interned_strings_usage']['used_memory'] / 1048576, 1), ' von ',
     round($s['interned_strings_usage']['buffer_size'] / 1048576, 1), ' MB', PHP_EOL;

Rufen Sie zuerst einige Seiten und das Backend auf, dann das Skript im Browser. Die Ausgabe im Labor nach wenigen Aufrufen einer frischen Installation:

aktiv: true
Speicher belegt: 30.2 MB
Speicher frei: 97.8 MB
Skripte im Cache: 522
Schlüssel maximal: 7963
Neustarts wegen Speichermangel: 0
Strings: 5.9 von 8 MB

So lesen Sie das Ergebnis: Wenn „Speicher frei“ gegen null geht oder „Neustarts wegen Speichermangel“ steigt, ist opcache.memory_consumption zu klein. Nähert sich „Skripte im Cache“ dem Wert „Schlüssel maximal“, reicht opcache.max_accelerated_files nicht. Ist der String-Puffer fast voll, erhöhen Sie opcache.interned_strings_buffer. Eine nackte WordPress-Installation enthielt im Labor bereits 1519 PHP-Dateien. Große Plugins bringen Hunderte weitere mit.

Verifizieren: Die Ausgabe zeigt aktiv: true. Sie haben notiert, wie voll Speicher, Schlüsseltabelle und String-Puffer nach typischer Nutzung sind, und das Skript danach gelöscht, da es Serverdetails verrät.

Schritt 3: Den richtigen Ort für eigene Einstellungen finden

PHP lädt Einstellungen aus mehreren Quellen. Wo eine Einstellung erlaubt ist, legt das PHP-Handbuch in der Spalte „Changeable“ fest. Alle OPcache-Größen wie opcache.memory_consumption, opcache.interned_strings_buffer und opcache.max_accelerated_files haben den Modus INI_SYSTEM. Sie wirken nur in der zentralen Konfiguration, nicht in .user.ini oder .htaccess. Welche Dateien PHP liest, zeigt auf dem Server:

php --ini

Im offiziellen Docker-Image lautete die Ausgabe gekürzt so:

Configuration File (php.ini) Path: /usr/local/etc/php
Loaded Configuration File:         (none)
Scan for additional .ini files in: /usr/local/etc/php/conf.d
Additional .ini files parsed:      ...
/usr/local/etc/php/conf.d/opcache-recommended.ini

Beachten Sie, dass php --ini die Dateien der Kommandozeile zeigt. Bei Debian und Ubuntu hat PHP-FPM ein eigenes Verzeichnis (unter /etc/php/ getrennt nach cli und fpm). Den für die Website maßgeblichen Pfad sehen Sie im Website-Zustand nicht, wohl aber eine phpinfo()-Ausgabe im Browser in der Zeile zu den zusätzlichen INI-Dateien. Legen Sie dort eine eigene Datei an, statt die mitgelieferte php.ini zu bearbeiten. So überschreibt kein Paket-Update Ihre Werte.

Umgebung	OPcache-Werte	memory_limit, Upload, Laufzeit
Eigener Server oder VPS	zusätzliche INI-Datei im conf.d-Verzeichnis	dieselbe INI-Datei
Shared Hosting	nur über das PHP-Menü des Hosters	PHP-Menü, .user.ini oder .htaccess
PHP-FPM oder CGI	zentrale INI-Datei	.user.ini im Webroot möglich
Apache mit mod_php	zentrale INI-Datei	php_value in der .htaccess

Im Labor mit Apache-Modul wurde eine .user.ini ignoriert, wie im PHP-Handbuch beschrieben: Diese Dateien verarbeitet nur die CGI- bzw. FastCGI-SAPI. Welche SAPI Ihre Website nutzt, zeigt der Website-Zustand unter Information > Server in der Zeile „PHP-SAPI“, etwa apache2handler für das Apache-Modul oder fpm-fcgi für PHP-FPM.

Verifizieren: Sie kennen die Server API Ihrer Website und das conf.d-Verzeichnis, das der Webserver-PHP tatsächlich einliest.

Schritt 4: OPcache und PHP-Grenzen einstellen

Legen Sie im conf.d-Verzeichnis eine Datei an, deren Name alphabetisch nach den mitgelieferten Dateien kommt, etwa zz-wordpress.ini. Später geladene Dateien überschreiben frühere Werte. Die folgenden Werte sind ein Ausgangspunkt für eine typische Unternehmenswebsite mit einigen Plugins, keine allgemeingültige Empfehlung:

; Eigene Einstellungen für WordPress
memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 120
max_input_vars = 3000

opcache.memory_consumption = 192
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 20000

Die Gründe:

• memory_limit: Grenze pro Aufruf. WordPress hebt den Wert selbst auf WP_MEMORY_LIMIT bzw. im Backend auf WP_MAX_MEMORY_LIMIT an, senkt einen höheren Serverwert aber nicht ab. So beschreibt es das WordPress-Handbuch.
• upload_max_filesize und post_max_size: Der Upload umfasst die Datei plus Formulardaten. Setzen Sie post_max_size mindestens so hoch wie upload_max_filesize, sonst greift die kleinere Grenze.
• max_input_vars: Menüs mit vielen Einträgen und umfangreiche Einstellungsseiten übertragen mehr als 1000 Felder. Überzählige Felder verwirft PHP ohne Fehlermeldung, Menüpunkte verschwinden dann beim Speichern.
• opcache.memory_consumption: gemeinsamer Speicher in Megabyte, einmal pro PHP-Pool. Wählen Sie ihn so, dass nach Schritt 2 genügend Reserve frei bleibt.
• opcache.max_accelerated_files: PHP rundet auf die nächste Primzahl aus einer festen Liste auf. Aus 20000 wurden im Labor 32531 Schlüssel, aus dem Image-Standard 4000 wurden 7963.

Laden Sie PHP anschließend neu. Bei Apache mit mod_php genügt ein apachectl graceful, bei PHP-FPM laden Sie den FPM-Dienst neu. Dessen Name hängt von Distribution und PHP-Version ab, systemctl list-units | grep fpm zeigt ihn. Auf Shared Hosting ohne Serverzugriff tragen Sie die erlaubten Werte im PHP-Menü des Hosters ein oder nutzen je nach SAPI eine .user.ini bzw. die .htaccess:

# Nur bei Apache mit mod_php, oberhalb von # BEGIN WordPress
php_value memory_limit 256M
php_value upload_max_filesize 64M
php_value post_max_size 64M

Bei .user.ini gilt der Cache-Zeitraum user_ini.cache_ttl, standardmäßig 300 Sekunden. Änderungen erscheinen also unter Umständen erst nach fünf Minuten.

Verifizieren: Im Labor zeigte das Prüfskript nach dem Neuladen 192 MB Gesamtspeicher (37,6 MB belegt, 154,4 MB frei), 32531 Schlüssel und einen String-Puffer von 16 MB. Kontrollieren Sie bei sich den Website-Zustand unter Information > Server: Dort müssen die neuen Werte stehen.

Schritt 5: Dateiprüfung und Deployments abstimmen

Standardmäßig prüft OPcache mit opcache.validate_timestamps = 1 und opcache.revalidate_freq = 2 höchstens alle zwei Sekunden, ob sich eine PHP-Datei geändert hat. Für WordPress ist das richtig, denn Updates tauschen laufend Dateien aus. Manche Tuning-Anleitungen empfehlen, die Prüfung mit opcache.validate_timestamps = 0 abzuschalten. Der Labortest zeigt die Folge: Nach dem Ändern einer PHP-Datei lieferte der Server weiter die alte Version aus, auch nach mehreren Sekunden. Erst ein Aufruf von opcache_reset() oder ein Neuladen von PHP brachte die neue Fassung.

Lassen Sie die Zeitstempelprüfung daher eingeschaltet, solange WordPress sich selbst aktualisiert. Die Abschaltung lohnt sich nur bei Deployments über eine Pipeline, die PHP nach jedem Einspielen gezielt neu lädt.

Genau an dieser Stelle zeigt sich, dass PHP-Einstellungen keine einmalige Aufgabe sind: Jedes größere Plugin-Update, jeder PHP-Versionswechsel des Hosters und jede neue Erweiterung verändert den Bedarf an Speicher und Cache. Wer diese Kontrolle nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de spielt Updates von WordPress, Plugins und Themes innerhalb von 48 Stunden mit Kompatibilitätsprüfung ein und sichert die Website wöchentlich auf externen Speicher.

Verifizieren: opcache.validate_timestamps steht im Website-Zustand bzw. in phpinfo() auf 1, und eine Änderung an einer Testdatei ist nach wenigen Sekunden sichtbar.

Typische Fehler

• „Invalid quantity "256MB": unknown multiplier "B"“: PHP kennt nur die Kürzel K, M und G. Im Labor führte memory_limit = 256MB zur Warnung „Failed to set memory limit to 256 bytes“, PHP behielt den vorherigen Wert. Bei opcache.memory_consumption gehört gar keine Einheit dazu, die Angabe ist in Megabyte.
• Wert erscheint nicht im Website-Zustand: Die Datei liegt im Verzeichnis der Kommandozeile statt im Verzeichnis von PHP-FPM, PHP wurde nicht neu geladen, oder eine später geladene Datei überschreibt den Wert. Prüfen Sie Pfad und Reihenfolge in phpinfo().
• .user.ini ohne Wirkung: Die Website läuft mit Apache-Modul, das diese Datei nicht liest (im Labor nachgestellt), oder der Cache von 300 Sekunden ist noch nicht abgelaufen.
• Serverfehler 500 nach .htaccess-Änderung: php_value ist unter PHP-FPM keine gültige Apache-Anweisung. Entfernen Sie die Zeilen per SFTP und nutzen Sie .user.ini.
• WP-CLI meldet OPcache deaktiviert: Das ist bei opcache.enable_cli = 0 normal und sagt nichts über den Webserver aus. Messen Sie im Browser wie in Schritt 2.
• Alte Plugin-Version aktiv trotz Update: Die Zeitstempelprüfung ist abgeschaltet. Laden Sie PHP neu und setzen Sie opcache.validate_timestamps wieder auf 1.
• „Allowed memory size of … bytes exhausted“ trotz höherem Limit: Ein Plugin hat ein echtes Speicherproblem, oder der Hoster deckelt den Wert. Wie Sie solche Fehler eingrenzen, beschreibt Weiße Seite und kritischen Fehler in WordPress beheben.

Häufige Fragen

Soll ich den JIT-Compiler von PHP 8 einschalten?

Für typische WordPress-Websites bringt er wenig, denn die Laufzeit wird vor allem von Datenbankabfragen und Dateizugriffen bestimmt. Seit PHP 8.4 steht opcache.jit laut PHP-Handbuch standardmäßig auf „disable“. Lassen Sie es dabei, solange Sie keinen Nutzen gemessen haben.

Ersetzt OPcache ein Caching-Plugin?

Nein. OPcache speichert kompilierten PHP-Code. Ein Seiten-Cache speichert fertige HTML-Seiten, ein Objekt-Cache Datenbankergebnisse. Das WordPress-Handbuch trennt diese Cache-Arten ausdrücklich, und die Konstante WP_CACHE hat mit OPcache nichts zu tun.

Wie hoch sollte memory_limit höchstens sein?

Das Limit gilt pro gleichzeitigem PHP-Prozess. Zehn parallele Aufrufe mit je 512 MB können theoretisch 5 GB belegen. Wählen Sie den Wert so, dass Ihr Server die maximale Zahl gleichzeitiger PHP-Prozesse tragen kann, und erhöhen Sie ihn gezielt statt pauschal.

Wo trage ich WP_MEMORY_LIMIT ein?

In der wp-config.php vor der Zeile mit wp-settings.php, etwa define( 'WP_MEMORY_LIMIT', '128M' );. Die Konstante wirkt nur, wenn PHP das Anheben erlaubt. Hinweise zur sicheren Bearbeitung dieser Datei finden Sie in wp-config.php härten.

Testumfang

Wir haben die Anpassung mit WordPress 7.1.2 unter Apache mit mod_php getestet, sowohl über eine eigene INI-Datei als auch über die .htaccess. Auffällig war, dass eine .user.ini unter mod_php einfach ignoriert wird.

PHP-FPM, nginx und die PHP-Menüs einzelner Hoster haben wir nicht geprüft. Probieren Sie Änderungen dort deshalb zuerst auf einer Kopie Ihrer Website aus.

Fazit

Die meisten Leistungs- und Upload-Probleme lösen Sie mit wenigen Zeilen in einer eigenen INI-Datei, sofern Sie vorher messen und die Datei an der Stelle ablegen, die der Webserver tatsächlich liest. OPcache braucht ausreichend Speicher und Schlüssel, aber keine abgeschaltete Zeitstempelprüfung. Prüfen Sie die Werte nach jedem PHP-Wechsel und jedem größeren Plugin erneut. Wenn Sie diese Pflege lieber abgeben möchten, übernimmt die WordPress-Wartung Updates und Backups für Ihre Website.

Weiterführende Anleitungen und Quellen

• PHP-Version für WordPress aktualisieren und Kompatibilität prüfen
• Weiße Seite und kritischen Fehler in WordPress beheben
• wp-config.php härten: Salts, Dateibearbeitung, Debug
• WordPress Advanced Administration: PHP Optimization
• PHP-Handbuch: OPcache Runtime Configuration
• PHP-Handbuch: .user.ini files