OPcache uitgelegd: de bytecodecache van PHP

Kort gezegd: OPcache is de ingebouwde bytecodecache van PHP. Volgens de handleiding slaat hij vooraf gecompileerde bytecode op in het gedeelde geheugen, zodat PHP scripts niet bij elk verzoek opnieuw hoeft te laden en te vertalen. Hij hoort sinds PHP 5.5.0 bij de standaardlevering. OPcache maakt PHP sneller, maar vervangt geen update: na een PHP-patch moeten alle PHP-processen opnieuw starten, het leegmaken van de cache is niet genoeg.

Wat doet OPcache precies?

Bij elk verzoek moet PHP een script lezen, ontleden en in opcodes vertalen, dus in de opdrachten voor de virtuele machine van de Zend Engine. Bij een CMS met honderden bestanden is dat veel werk dat zich voortdurend herhaalt.

OPcache slaat het resultaat van deze vertaling op in het gedeelde geheugen (shared memory). Alle workers van een PHP-FPM-dienst of alle Apache-processen met mod_php hebben er toegang toe. Verandert een bestand niet, dan wordt de bytecode ervan direct hergebruikt.

OPcache wordt geladen als Zend-extensie, niet als gewone extensie:

; Linux (pad afhankelijk van het pakket)
zend_extension=opcache.so
; Windows
; zend_extension=php_opcache.dll

Volgens de handleiding moet OPcache vóór Xdebug worden geladen als beide actief zijn.

Belangrijk is wie eigenaar is van het gedeelde geheugen. Bij PHP-FPM maakt het masterproces het aan en gebruiken alle workers van alle pools van deze dienst het. Bij mod_php hoort het bij het hoofdproces van Apache. Een herstart van de dienst leegt de cache daarom volledig, een enkele nieuwe worker daarentegen niet. Voor de opdrachtregel is er geen gedeeld geheugen over aanroepen heen, omdat elke aanroep een eigen proces is; daar staat OPcache standaard uit.

Voor beslissers volstaat een vuistregel: OPcache is op productieservers bijna altijd zinvol, maar vraagt een duidelijk verloop voor deployments en updates.

Welke OPcache-instellingen tellen?

De volgende waarden komen van de configuratiepagina van de PHP-handleiding. De kolom „Wijzigbaar” laat zien waar een instelling mag worden gezet: INI_SYSTEM alleen in php.ini of serverconfiguratie, INI_ALL overal.

Een typische productieconfiguratie kan er zo uitzien. Controleer de waarden vooraf met uw toepassing:

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

Wie opcache.validate_timestamps=0 instelt, wint wat prestaties. Dan herkent OPcache gewijzigde bestanden echter helemaal niet meer en heeft elke deployment een reset van de cache of een herstart nodig.

De cache bekijken en gericht legen

OPcache brengt eigen functies mee, waaronder opcache_get_status(), opcache_get_configuration(), opcache_invalidate() en opcache_reset(). Een korte, lezende blik op de vulling:

<?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);

Op servers met meerdere websites mag niet elke toepassing de cache van alle andere kunnen legen of uitlezen. Daarvoor dient opcache.restrict_api: alleen scripts onder het opgegeven pad mogen de API-functies aanroepen.

JIT: de machinecodecompiler in OPcache

Sinds PHP 8.0 bevat OPcache een JIT-compiler die opcodes naar machinecode vertaalt. Volgens de JIT-RFC is hij een vrijwel zelfstandig onderdeel van OPcache en slaat hij de gegenereerde code op in een eigen gebied van het gedeelde geheugen. Hij wordt aangestuurd via opcache.jit en opcache.jit_buffer_size. Sinds PHP 8.4.0 staat opcache.jit standaard op disable. Wanneer de JIT loont, legt het artikel JIT en prestaties in PHP 8 uit.

OPcache en beveiliging: wat na PHP2Shell geldt

OPcache is geen beveiligingsinstrument, maar heeft gevolgen voor de beveiliging. Drie punten zijn na PHP2Shell belangrijk:

1. Een cachereset is geen update. opcache_reset() leegt alleen gecachete scripts. De interpreter met de lekken CVE-2026-109618 en CVE-2026-109619 blijft in het geheugen tot alle processen opnieuw zijn gestart. Hoe dat gaat, staat onder PHP-FPM en alle workers opnieuw starten.
2. Ingeslopen code kan in de cache blijven voortleven. Is een bestand gemanipuleerd en later vervangen, dan kan bij uitgeschakelde tijdstempelcontrole de oude versie blijven draaien. Na een opschoning hoort daarom een herstart erbij.
3. Gedeeld geheugen vraagt scheiding. Op servers met meerdere klanten helpen eigen PHP-FPM-pools per website en opcache.validate_permission en opcache.restrict_api. Een map voor opcache.file_cache mag alleen voor de PHP-gebruiker beschrijfbaar zijn.

Hoe helpt PHP SOS concreet?

• Configuratie controleren: Wij lezen de actieve OPcache-configuratie per uitvoeringsmodus uit en vergelijken die met uw toepassing.
• Deployments beveiligen: Wij richten een vast verloop in voor cachereset en herstart, zodat er geen oude codeversie blijft draaien.
• Klanten scheiden: In het kader van de serverhardening stellen wij gescheiden pools, restrict_api en passende rechten in.
• Na updates controleren: Wij bewijzen aan de hand van processtarttijden dat de bijgewerkte interpreter echt actief is.

Veelgestelde vragen

Bronnen

• PHP-handleiding: OPcache
• PHP-handleiding: OPcache-configuratie
• PHP-handleiding: OPcache-installatie
• PHP RFC: JIT