--- title: "PHP-OPcache und PHP-Einstellungen für WordPress messen und anpassen" date: 2026-09-30T21:46:48+02:00 modified: 2026-11-10T17:20:31+01:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-php-opcache-einstellungen-memory-limit-upload-optimieren keywords: - WordPress - PHP - OPcache - Performance - Hosting reading_time: 10 --- # 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 mit WordPress 7.1.2 und PHP 8.4.26 unter Apache geprüft, inklusive der typischen Fehler. **Kurzfassung:** Lesen Sie die aktuellen Werte unter *Werkzeuge > Website-Zustand > Information > Server* ab, nicht per WP-CLI. Prüfen Sie mit einem kurzen Statusskript, ob OPcache im Webserver läuft und wie voll Speicher und Schlüsseltabelle sind. Legen Sie eigene Werte in einer zusätzlichen INI-Datei ab, nicht in der originalen `php.ini`. OPcache-Werte wie `opcache.memory_consumption` lassen sich nur systemweit setzen, `memory_limit` und Upload-Grenzen auch per `.user.ini` (PHP-FPM) oder `.htaccess` (Apache-Modul). Laden Sie PHP danach neu und kontrollieren Sie das Ergebnis erneut im Website-Zustand. ## Voraussetzungen - [ ] **WordPress:** eine aktuelle Installation, im Beispiel WordPress 7.1.2 in deutscher Sprache. - [ ] **PHP:** PHP 8.x, im Beispiel 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](https://s-edv.com/anleitungen/wordpress-php-version-aktualisieren-kompatibilitaet-pruefen). - [ ] **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 Beispiel-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 Test 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. > **Prüfen:** 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`: Datei: `oc-pruefung-7f3a.php` ```php **Prüfen:** 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: ```bash $ php --ini ``` Im offiziellen Docker-Image lautete die Ausgabe gekürzt so: ```plaintext 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` | Beim Apache-Modul wird 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. > **Prüfen:** 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: Datei: `zz-wordpress.ini` ```ini ; 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 Test 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`: ```apache # 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. > **Prüfen:** Im Test 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 Test 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. PHP-Einstellungen sind keine einmalige Aufgabe: 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=55) 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. > **Prüfen:** `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 Test 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 Test 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](https://s-edv.com/anleitungen/wordpress-update-fehler-beheben-weisse-seite-kritischer-fehler). ## 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](https://s-edv.com/anleitungen/wordpress-wp-config-haerten-salts-dateibearbeitung-debug). ## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=55) Updates und Backups für Ihre Website. ## Weiterführende Anleitungen und Quellen - [PHP-Version für WordPress aktualisieren und Kompatibilität prüfen](https://s-edv.com/anleitungen/wordpress-php-version-aktualisieren-kompatibilitaet-pruefen) - [Weiße Seite und kritischen Fehler in WordPress beheben](https://s-edv.com/anleitungen/wordpress-update-fehler-beheben-weisse-seite-kritischer-fehler) - [wp-config.php härten: Salts, Dateibearbeitung, Debug](https://s-edv.com/anleitungen/wordpress-wp-config-haerten-salts-dateibearbeitung-debug) - [WordPress Advanced Administration: PHP Optimization](https://developer.wordpress.org/advanced-administration/performance/php/) - [PHP-Handbuch: OPcache Runtime Configuration](https://www.php.net/manual/en/opcache.configuration.php) - [PHP-Handbuch: .user.ini files](https://www.php.net/manual/en/configuration.file.per-user.php)