OPcache und JIT in PHP-8.3-Produktion — was tatsächlich den Unterschied macht

Das OPcache von PHP 8.3 ist eine der ROI-stärksten Konfigurationsänderungen in der gesamten Stack. Die Default-Konfig ist Dev-freundlich (häufige Revalidierung, bescheidener Speicher). Die produktionsrichtige Konfig ist eine kleine Änderung, die routinemäßig 30-40 % CPU-Nutzung auf Laravel- und WordPress-Workloads spart. JIT ist der trübere Verwandte — manchmal ein klarer Gewinn, manchmal neutral, gelegentlich eine Regression.

Das ist, was wir ausliefern und warum.

Die Produktions-Konfig

opcache.enable=1
opcache.memory_consumption=512
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.save_comments=1
opcache.fast_shutdown=1
opcache.jit_buffer_size=128M
opcache.jit=tracing

Der wirkungsvollste Flag ist validate_timestamps=0. Er sagt OPcache, nie zu prüfen, ob eine Datei geändert wurde — er vertraut einfach dem Cache. Trade-off: Deployments erfordern ein explizites opcache_reset() oder einen PHP-FPM-Reload, was Ihre Deploy-Pipeline sowieso machen sollte.

Der vollständige Beitrag behandelt:

• Warum validate_timestamps=0 in jede Produktions-Konfig gehört
• memory_consumption und max_accelerated_files für Ihre Codebase dimensionieren
• JIT-Modi (function, tracing) — und die Workloads, bei denen jeder hilft
• Wann JIT tatsächlich schadet (PHP-als-Templating, überwiegend I/O-Workloads)
• Die Ausgabe von opcache_get_status() lesen, um zu verifizieren, dass es seinen Job macht
• Cold-Start-Strategien für ephemere Container (Preloading vs Lazy)

Wir liefern diese Konfiguration auf jeder gemanagten PHP-Installation aus.