Permanent Opcache

Wanneer een health check wordt uitgevoerd door WordPress en er wordt een melding gedaan dat permanente objectcache ontbreekt dan heb ik hier de volgende tip.

Gebruik de plugin SQLite Object Cache . Zie de informatie hier : https://wordpress.org/plugins/sqlite-object-cache/
Een permanente objectcache draagt ​​bij aan goede prestaties van uw website. Deze cache maakt gebruik van de veelgebruikte SQLite3-extensie en optioneel de igbinary- en APCu-extensies voor PHP. Veel hostingproviders bieden deze extensies aan en ze zijn eenvoudig te installeren op een server die u zelf beheert.

Het is een fascinerend onderwerp omdat het precies de plek raakt waar moderne software (WordPress met de Block Editor) botst met “ouderwetse” serverinstellingen. Veel hostingproviders draaien op configuraties die tien jaar geleden perfect waren, maar nu de rem zetten op je website.

Hier is het verhaal achter de interned_strings_buffer en waarom die 8MB tegenwoordig vaak een flessenhals is.

Wat zijn ‘Interned Strings’ eigenlijk?

Stel je voor dat PHP een boek schrijft (jouw webpagina). In dat boek komen bepaalde woorden duizenden keren voor, zoals wp-content, plugin, div of namen van functies.

Zonder ‘interning’ zou PHP voor elk woord dat hij tegenkomt een nieuw stukje geheugen reserveren. Dat is enorm inefficiënt. Met Interned Strings zegt PHP: “Ik sla het woord ‘Gutenberg’ één keer op in een speciale buffer. Elke keer dat ik het weer nodig heb, verwijs ik gewoon naar dat ene opgeslagen plekje.”

Dit bespaart niet alleen geheugen, maar maakt de verwerking ook razendsnel omdat PHP niet steeds nieuwe stukjes geheugen hoeft te alloceren.

Waarom de Block Editor (Gutenberg) alles veranderde

In de tijd van de Classic Editor was WordPress relatief “plat”. Je had tekst, wat HTML-tags en dat was het wel. De standaardwaarde van 8MB voor de interned strings buffer was toen ruim voldoende voor de kern van WordPress en een paar plugins.

Toen kwam de Block Editor. De architectuur daarvan is fundamenteel anders:

  1. JSON-overal: De editor communiceert constant met de database via enorme JSON-bestanden. JSON zit vól met unieke strings (sleutels, eigenschappen, waarden).
  2. Blokken-logica: Elk blok (een paragraaf, een afbeelding, een kolom) heeft zijn eigen metadata en attributen.
  3. Hogere complexiteit: Moderne WordPress-sites gebruiken vaak sitebuilders of uitgebreide blok-bibliotheken die tienduizenden unieke strings genereren tijdens het renderen van een pagina.

De 8MB Muur: Wat gebeurt er als het vol is?

Wanneer die buffer van 8MB volloopt — en bij een moderne WordPress-site met 20+ plugins gebeurt dat binnen enkele minuten — stopt PHP niet met werken, maar het wordt wel inefficiënt.

  • Geen nieuwe interning: PHP kan geen nieuwe unieke strings meer opslaan in de snelle buffer. Hij moet terugvallen op het “oude” systeem waarbij strings telkens opnieuw in het gewone geheugen worden aangemaakt.
  • Performance degradatie: Je merkt dat de backend (het bewerken van pagina’s) traag begint aan te voelen. Het opslaan van een post duurt net een seconde langer.
  • OPcache Restarts: In sommige gevallen raakt de hele OPcache in de war of moet deze vaker herstarten (flushen), waardoor je hele site tijdelijk vertraagt omdat alle scripts opnieuw gecompileerd moeten worden.

Waarom staan providers dan nog op 8MB?

De meeste hostingproviders kiezen voor de veiligste weg voor henzelf, niet voor de snelste weg voor jou. Als ze op een server 500 websites hosten en ze verhogen de buffer van 8MB naar 64MB voor iedereen, dan kost dat plotseling 28GB extra aan RAM-geheugen op die server. Veel “budget” providers laten de instelling daarom op de PHP-standaard staan, ook al is die verouderd.

De Gouden Instelling: 32MB of 64MB

Voor een professionele WordPress-omgeving anno 2026 is dit de aanbeveling:

  • 32MB: Ruimschoots voldoende voor de meeste zakelijke websites met een gemiddeld aantal plugins.
  • 64MB: Noodzakelijk voor webshops (WooCommerce) of zware sites met complexe pagebuilders zoals Elementor of uitgebreide FSE-themes (Full Site Editing).

Hoe controleer je dit?

Je kunt een simpel PHP-bestandje maken (bijvoorbeeld : info.php) met de code <?php phpinfo(); ?> en zoeken naar opcache.interned_strings_buffer

Nog beter: kijk naar de opcache_get_status() output. Als daar de waarde buffer_size gelijk is aan used_memory, dan zit je tegen je plafond aan en verlies je snelheid.

Hier is de instelling die werkt.
Het bestand custom.ini is via de terminal te benaderen.
De naam kan verschillen .user.ini of .php.ini net als de php versie.
In dit voorbeeld is dat dus custom.ini met PHP 83
nano /etc/cl.php.d/alt-php83/custom.ini

Inhoud van de ini file is:
opcache.memory_consumption=3072
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=40000
De terminal is te benaderen via de Directadmin of Cpanel.

Hier is de uitleg per regel

opcache.memory_consumption=3072

  • Wat het is: De totale hoeveelheid geheugen (in megabytes) die OPcache mag gebruiken om gecompileerde PHP-scripts op te slaan.
  • Waarde: 3072 MB (3 GB).
  • Betekenis: Dit is een zeer royale instelling. De standaardwaarde is vaak 128 MB. Met 3 GB geef je PHP extreem veel ruimte om duizenden scripts gecached te houden. Dit is meestal alleen nodig voor zeer grote applicaties of servers waarop veel verschillende sites draaien.

opcache.interned_strings_buffer=32

  • Wat het is: Een “interned string” is een techniek waarbij PHP identieke tekststrings (zoals variabelenamen of veelgebruikte woorden in je code) slechts één keer in het geheugen opslaat. Deze buffer is specifiek voor dat doel.
  • Waarde: 32 MB.
  • Betekenis: De standaardwaarde is meestal 8 MB. Door dit te verhogen naar 32 MB, help je de efficiëntie van het geheugengebruik te verbeteren, omdat PHP minder vaak strings hoeft te kopiëren. Dit is een gezonde instelling voor moderne frameworks.

opcache.max_accelerated_files=40000

  • Wat het is: Dit bepaalt het maximale aantal PHP-bestanden dat tegelijkertijd in de cache kan worden opgeslagen.
  • Waarde: 40.000.
  • Betekenis: Hiermee kan de server tot 40.000 verschillende bestanden onthouden. Voor een gemiddelde site zijn 10.000 bestanden vaak al genoeg, maar complexe systemen (zoals Magento of sites met veel plug-ins) kunnen baat hebben bij deze hogere limiet.

Samenvattend

Deze specifieke configuratie is bedoeld voor een krachtige server die een zeer grote PHP-applicatie draait. Met 3 GB aan cache en ruimte voor 40.000 bestanden zorg je ervoor dat bijna alle PHP-code direct uit het razendsnelle RAM-geheugen kan worden gelezen.

Een kleine tip: Controleer of je server daadwerkelijk genoeg fysiek RAM-geheugen heeft. Als je 3 GB toewijst aan OPcache terwijl je server maar 4 GB totaal heeft, kan dit leiden tot problemen met andere processen (zoals je database).

Wanneer dit ingevoerd is, zal in de nachtverwerking de server deze gegevens oppikken en de volgende dag is het ingesteld.
Wanneer je dan nu een health check doet in WordPress zijn er geen meldingen of aanbevelingen meer.
En je website is een stuk sneller en efficiënter.

Archief