Bug opgelost in productie — ticket gesloten. Gebruikers zien de fout nog steeds. CDN-cache? Leeg. Opcoderen? opcache.validate_timestamps=0 vanuit een “performance” instelling: de PHP-bestanden worden bijgewerkt op schijf, maar de oude bytecode blijft veertig minuten beschikbaar tot de paniekerige herstart van PHP-FPM.
OPcache is een versnelling: slecht beheerd in productie, het is een codecache die uw implementaties negeert. Het probleem is niet “het wissen van de cache”; het synchroniseert de release op schijf en PHP-workers zonder een 502-cascade te veroorzaken.
Gezonde implementatiecyclus
Een betrouwbare PHP-implementatie volgt een gedocumenteerde volgorde:
- Atomic release:
/releases/20260719/plus symbolische linkcurrent. - Opstellen installatie, migraties, voorverwarmen van applicatiecache.
php artisan optimizeof Symfony cache indien van toepassing.- PHP-FPM herladen:
systemctl herlaad php8.2-fpm(sierlijk). - Rooktest bij gezondheidscontrole.
- Backspace = symlink terugzetten plus herladen.
Bij het 'herladen' worden werknemers geleidelijk gerecycled - de huidige verzoeken eindigen; nieuwe werkers laden een nieuwe OP-cache. Een plotselinge 'herstart' veroorzaakt een afsluiting; 'reload' heeft de voorkeur voor ononderbroken implementatie.
herstart brutaal versus herlaad sierlijk: de eerste onderbreekt de service; de tweede behoudt de huidige verbindingen.
validate_timestamps: het compromis dat je moet begrijpen
| Instelling | Gedrag | Gebruik |
|---|---|---|
validate_timestamps=1 | stat() in bestand, compileert opnieuw als mtime verandert | Ontwikkeling, pre-productie |
validate_timestamps=0 | controleer de schijf nooit opnieuw | Productie plus herladen bij elke inzet |
Met revalidate_freq=0 en validate=1 controleert elk verzoek de schijf – een onnodige I/O-belasting in de productie. Het paar validate_timestamps=0 plus scripted FPM reload is de standaard voor teams die meerdere keren per week inzetten.
Invalidatiestrategieën
A — FPM herladen (aanbevolen) Stap na de implementatie in het script: systemctl reload php-fpm. Eenvoudig, voorspelbaar, zonder grote onderbrekingen.
B — opcache_reset() in de opdrachtregel na de implementatie Via one-shot SSH – acceptabel als er maar één PHP-FPM-pool is. Nooit in een HTTP-verzoek.
C — Geleidelijke implementatie op N-servers Load balancer in afvoer → implementatie → herladen → reactivering. Geen downtime op een cluster.
D — opcache.file_cache Tweede laag op schijf: let tijdens de implementatie op de synchronisatie tussen knooppunten.
Vallen en containers in meerdere versies
- Blauwgroen met twee releases: gemengde werkers bij gedeeltelijk herladen: voltooi het herladen op alle knooppunten voordat u van verkeer wisselt.
- PHP 7.4+ vooraf laden: een wijziging van het vooraf geladen bestand vereist een volledige herstart, geen eenvoudig herladen.
- Docker: nieuwe afbeelding = nieuwe container, nieuwe OPcache. Volume mount voor code = hetzelfde
validate_timestampsprobleem.
Op gedeelde hosting, geen self-service FPM-herladen - FTP-implementatie met validate_timestamps=1 opgelegd of ondersteuningsticket. Reden te meer voor een VPS of PaaS als je veelvuldig inzet.
De top: OPcache zonder implementatieprocedure is onbedoelde A/B-testen
Dit is wat de "prestatie" -instellingen vergeten te documenteren.
PHP-implementatiechecklist: symlink plus FPM herladen gedocumenteerd - niet "we uploaden en hopen".
Beslis en ga vooruit zonder blinde vlek
Gedurende een halve dag kunt u uw PHP-implementaties beveiligen:
- Geslaagd
validate_timestamps=0in productie met scripted FPM herladen. - Stel een atomaire implementatie in via een symlink.
- Maak een rooktest na het opladen verplicht.
- Niet toestaan
opcache_reset()in webeindpunten. - Plan voor een gefaseerde implementatie als u meerdere servers heeft.
Documenteer de volledige reeks in uw implementatierunbook: wie het opnieuw laden initieert, hoe u kunt verifiëren dat alle werknemers zijn gerecycled en welke test bevestigt dat de nieuwe code met succes is weergegeven. Kruisverwijzingen met PHP Profiling om de impact van een slechte implementatie te meten, en blue-green deployment voor architecturen met meerdere instanties.
Veelgestelde vragen
Waarom wordt de oude code uitgevoerd nadat deze is geïmplementeerd?
OPcache houdt de gecompileerde bytecode in het geheugen. Met validate_timestamps=0 activeren gewijzigde bestanden op schijf pas opnieuw laden als een werker wordt gerecycled via een FPM-herlaadbeurt.
is opcache_reset() in prod veilig?
Nee in webverzoek: het is een brutale wereldwijde reset. Geef de voorkeur aan een keurige herlaadbeurt van PHP-FPM of een reset van de opdrachtregel na de implementatie, exclusief gebruikersverkeer.
validate_timestamps=1 in productie?
Mogelijk in pre-productie. In productie voegt dit stat()-aanroepen toe aan elke include. Het algemene compromis blijft validate_timestamps=0 plus FPM-herladen bij elke implementatie.
Helpt atomaire inzet?
Ja. De symlink-schakelaar plus FPM-herladen synchroniseert alle werkers in dezelfde bestandsboom, zonder oude en nieuwe releases te vermengen.
Als OPcache na een implementatie niet voor het feest is uitgenodigd, onderhoud je twee versies van de site: één in git, één in RAM.