OPcache erklärt: Der Bytecode-Cache von PHP

Kurz gesagt: OPcache ist der eingebaute Bytecode-Cache von PHP. Laut Handbuch speichert er vorkompilierten Bytecode im gemeinsamen Speicher, sodass PHP Skripte nicht bei jeder Anfrage neu laden und übersetzen muss. Er gehört seit PHP 5.5.0 zum Lieferumfang. OPcache macht PHP schneller, ersetzt aber kein Update: Nach einem PHP-Patch müssen alle PHP-Prozesse neu starten, nicht nur der Cache geleert werden.

Was macht OPcache genau?

Bei jeder Anfrage muss PHP ein Skript lesen, zerlegen und in Opcodes übersetzen, also in die Befehle für die virtuelle Maschine der Zend Engine. Bei einem CMS mit Hunderten Dateien ist das viel Arbeit, die sich ständig wiederholt.

OPcache speichert das Ergebnis dieser Übersetzung im gemeinsamen Speicher (Shared Memory). Alle Worker eines PHP-FPM-Dienstes oder alle Apache-Prozesse mit mod_php greifen darauf zu. Ändert sich eine Datei nicht, wird ihr Bytecode direkt wiederverwendet.

Geladen wird OPcache als Zend-Erweiterung, nicht als normale Erweiterung:

; Linux (Pfad je nach Paket)
zend_extension=opcache.so
; Windows
; zend_extension=php_opcache.dll

Laut Handbuch soll OPcache vor Xdebug geladen werden, wenn beide aktiv sind.

Wichtig ist, wem der gemeinsame Speicher gehört. Bei PHP-FPM legt der Master-Prozess ihn an, und alle Worker aller Pools dieses Dienstes nutzen ihn. Bei mod_php gehört er zum Apache-Hauptprozess. Ein Neustart des Dienstes leert den Cache deshalb vollständig, ein einzelner neuer Worker dagegen nicht. Für die Kommandozeile gibt es keinen gemeinsamen Speicher über Aufrufe hinweg, weil jeder Aufruf ein eigener Prozess ist; dort ist OPcache standardmäßig aus.

Für Entscheider genügt eine Faustregel: OPcache ist auf Produktionsservern fast immer sinnvoll, verlangt aber einen klaren Ablauf für Deployments und Updates.

Welche OPcache-Einstellungen zählen?

Die folgenden Werte stammen aus der Konfigurationsseite des PHP-Handbuchs. Die Spalte „Änderbar“ zeigt, wo eine Einstellung gesetzt werden darf: INI_SYSTEM nur in php.ini oder Serverkonfiguration, INI_ALL überall.

Eine typische Produktionskonfiguration könnte so aussehen. Prüfen Sie die Werte vorher mit Ihrer Anwendung:

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60
opcache.restrict_api=/var/www/admin-tools

Wer opcache.validate_timestamps=0 setzt, gewinnt etwas Leistung. Dann erkennt OPcache geänderte Dateien aber gar nicht mehr, und jedes Deployment braucht einen Reset des Caches oder einen Neustart.

Den Cache beobachten und gezielt leeren

OPcache bringt eigene Funktionen mit, darunter opcache_get_status(), opcache_get_configuration(), opcache_invalidate() und opcache_reset(). Ein kurzer, lesender Blick auf den Füllstand:

<?php
$status = opcache_get_status(false);
if ($status === false) {
    exit("OPcache ist nicht aktiv.\n");
}
printf("Gecachte Skripte: %d\n", $status['opcache_statistics']['num_cached_scripts']);
printf("Freier Speicher: %.1f MB\n", $status['memory_usage']['free_memory'] / 1048576);

Auf Servern mit mehreren Websites sollte nicht jede Anwendung den Cache aller anderen leeren oder auslesen können. Dafür ist opcache.restrict_api gedacht: Nur Skripte unterhalb des angegebenen Pfads dürfen die API-Funktionen aufrufen.

JIT: der Maschinencode-Compiler im OPcache

Seit PHP 8.0 enthält OPcache einen JIT-Compiler, der Opcodes in Maschinencode übersetzt. Laut JIT-RFC ist er ein nahezu eigenständiger Teil von OPcache und legt den erzeugten Code in einem eigenen Bereich des gemeinsamen Speichers ab. Gesteuert wird er über opcache.jit und opcache.jit_buffer_size. Seit PHP 8.4.0 steht opcache.jit standardmäßig auf disable. Wann sich der JIT lohnt, erklärt der Beitrag JIT und Performance in PHP 8.

OPcache und Sicherheit: was nach PHP2Shell gilt

OPcache ist kein Sicherheitswerkzeug, hat aber Folgen für die Sicherheit. Drei Punkte sind nach PHP2Shell wichtig:

1. Ein Cache-Reset ist kein Update. opcache_reset() leert nur gecachte Skripte. Der Interpreter mit den Lücken CVE-2026-109618 und CVE-2026-109619 bleibt im Speicher, bis alle Prozesse neu gestartet sind. Wie das geht, steht unter PHP-FPM und alle Worker neu starten.
2. Eingeschleuster Code kann im Cache weiterleben. Wurde eine Datei manipuliert und später ersetzt, kann bei ausgeschalteter Zeitstempelprüfung die alte Fassung weiter ausgeführt werden. Nach einer Bereinigung gehört deshalb ein Neustart dazu.
3. Gemeinsamer Speicher braucht Trennung. Auf Servern mit mehreren Kunden helfen eigene PHP-FPM-Pools je Website sowie opcache.validate_permission und opcache.restrict_api. Ein Verzeichnis für opcache.file_cache darf nur für den PHP-Benutzer beschreibbar sein.

Wie hilft PHP SOS konkret?

• Konfiguration prüfen: Wir lesen die aktive OPcache-Konfiguration je Betriebsart aus und gleichen sie mit Ihrer Anwendung ab.
• Deployments absichern: Wir richten einen festen Ablauf für Cache-Reset und Neustart ein, damit keine alte Codefassung weiterläuft.
• Mandanten trennen: Im Rahmen der Server-Härtung setzen wir getrennte Pools, restrict_api und passende Rechte.
• Nach Updates kontrollieren: Wir belegen über Prozess-Startzeiten, dass der aktualisierte Interpreter wirklich aktiv ist.

Häufige Fragen

Quellen

• PHP-Handbuch: OPcache
• PHP-Handbuch: OPcache-Konfiguration
• PHP-Handbuch: OPcache-Installation
• PHP RFC: JIT