...
webhostinglogo

WordPress query cache: Waarom het meestal meer kwaad dan goed doet

De WordPress Query Cache belooft kortere laadtijden, maar veroorzaakt in de praktijk vaak ongeldigmakingen, Latency en inconsistente inhoud. Ik zal je laten zien waarom deze cache vaak de prestaties van WordPress opslokt en hoe ik in plaats daarvan een stabiele snelheid kan bereiken.

Centrale punten

  • InvalidatieFrequente schrijfbewerkingen legen de cache en genereren overhead.
  • LatencyExterne caches voegen connectietijd toe, wat vaak alle besparingen teniet doet.
  • InconsistentieVerouderde invoer leidt tot oude prijzen, onjuiste lijsten of lege winkelmandjes.
  • RAMDe cache concurreert met PHP, MySQL en Nginx/Apache om geheugen.
  • AlternatievenPage caching, OPcache en schone query's zorgen voor betrouwbare winst.

Hoe de WordPress query cache echt werkt

MySQL slaat de resultaten van SELECT-query's op met de exacte SQL-tekst in de Cache en levert het opnieuw met een identieke query, waardoor de uitvoering wordt opgeslagen. In WordPress worden INSERTs, UPDATEs en DELETEs echter continu ontvangen, waardoor de query cache voor de betreffende tabellen onmiddellijk wordt geladen. uitgeschakeld. Ik zie regelmatig een eindeloze lus in logs: vullen, leegmaken, weer vullen - de server verbrandt CPU-tijd zonder enig merkbaar voordeel. Bovendien botst de MySQL query cache met WordPress' eigen mechanismen zoals transients en de object cache, waardoor de latency toeneemt in plaats van afneemt. Degenen die de WordPress query cache inschakelen bouwen daarom vaak een dubbele caching laag op die sneller kapot gaat dan het kan ondersteunen.

Definitie: Wat wordt hier echt gecached

Ik maak onderscheid tussen drie niveaus, die vaak door elkaar worden gehaald:

  • MySQL Query CacheResultaat cache voor identieke SELECT statements. Elke schrijfbewerking op de betreffende tabellen maakt entries ongeldig. Dit is contraproductief in moderne OLTP workloads zoals WordPress. In nieuwere MySQL versies is deze cache ook verouderd; het bestaat nog steeds in MariaDB, maar daar schakel ik het ook uit.
  • InnoDB bufferpool: Geen resultatencache, maar een paginacache voor data- en indexpagina's. Het is het robuuste, bewezen pad voor terugkerende leestoegang. Een stevige bufferpoolgrootte levert vaak meer op dan welke resultaatcache dan ook.
  • WordPress object cache/transientsCache aan de applicatiekant (vaak Redis/Memcached), waarin voorbereide structuren zoals WP_Query resultaten, opties of HTML-fragmenten worden opgeslagen. Deze laag helpt alleen als leestoegang de regel is en invalidatie betrouwbaar werkt.

In het dagelijks leven heb ik gemerkt dat de bufferpool en een goed gekozen paginacache de grootste hefbomen zijn. Extra query caching levert zelden een netto winst op, maar verhoogt de complexiteit, latentie en het risico op inconsistenties.

Waarom het vertraagt in plaats van helpt

Op gedeelde hosts of met WooCommerce genereert de cache merkbaar Vertraging, omdat elke netwerkverbinding met Redis of Memcached tijd kost en nauwelijks hits oplevert. Zelfs op snelle machines verlies ik vaak milliseconden per verzoek, die optellen met het verkeer en de time-to-first bytes opblazen. Daarnaast is er het risico van verouderde resultaten als er invalidatiehaken ontbreken of plugins verkeerd werken - plotseling ziet een klant een onjuist resultaat. Prijs of aandelen gemist. Als je meer wilt weten, raad ik je mijn ervaringsrapport aan Object Cache remmen omdat soortgelijke patronen van toepassing zijn op query caching niveaus. Gemiddeld bereikt schone directe toegang tot de database met een goed schema en OPcache betere en stabielere responstijden.

Cache stampede, TTL en coördinatie

Een terugkerend patroon in WordPress stacks is de Cache-stampedeEen item verloopt, veel verzoeken doen dezelfde dure query op hetzelfde moment en genereren pieken. Query- en objectcaches zonder coördinatie verergeren dit. Ik gebruik drie strategieën om dit te voorkomen:

  • Vergrendelen/Coalescing: Eén verzoek bouwt de invoer, de anderen wachten even of geven de oude waarde terug (stale-while-revalidate) en wordt op de achtergrond bijgewerkt.
  • Nuttige TTL'sGeen willekeurige 24h standaarden. Productlijsten of prijsfragmenten krijgen korte TTL's (seconden/minuten), catalogusmetagegevens langere.
  • Gebeurtenisgebaseerde ongeldigverklaringIn plaats van botte tijdreeksen, gebruik ik haken (bijvoorbeeld voor post-updates) om alleen aangetaste sleutels te verwijderen - of beter: om specifiek de paginacache te vernieuwen.

Belangrijk: In WordPress Transiënten Effectief met actieve persistente objectcache permanent opgeslagen. Als u hier geen schone ongeldigverklaring toepast, zult u inconsistenties en foutpatronen creëren die moeilijk te reproduceren zijn.

Typische symptomen op productieve sites

Als de WordPress query cache beschadigd is, herken ik dit eerst aan een fluctuerende Reactietijd, die plotseling omhoog en omlaag gaat zonder dat er iets aan de code is veranderd. s Avonds, als er meer bestellingen binnenkomen, stapelen de ongeldigmakingen zich op en komt de site in een spiraal van cache misses en nieuwe vermeldingen terecht. De monitoring laat dan vluchtige CPU-pieken zien in MySQL, terwijl PHP-FPM wacht op nieuwe resultaten. Tegelijkertijd melden klanten mismatches zoals dubbele reacties, lege winkelmandjes of vertraagde updates van productwidgets. Lock-waarschuwingen verschijnen ook steeds vaker in logboeken omdat concurrerende processen constant naar dezelfde tabellen schrijven en zo de cache ongeldig maken.

Cacheniveaus: volgorde in plaats van stapelen

Ik geef prioriteit aan caches op basis van de impactketen:

  1. Browser/CDN/randcache voor volledig openbare pagina's, onderscheiden door cookies/headers.
  2. Pagina cache in de stack (webserver/plugin), idealiter met preload en gerichte purge bij gebeurtenissen.
  3. OPcache voor consistent gecompileerde PHP-bytecode.
  4. Object cache alleen selectief voor dure, zelden veranderende objecten.
  5. Database met een sterk schema, indices en een grote bufferpool.

Wie zich aan deze volgorde houdt, vermindert niet alleen de TTFB, maar vooral ook de variantie - wat gebruikers ervaren als „rukken“.

Betere opties voor echte snelheid

Ik krijg betrouwbaar betere prestaties als ik voor het eerst Pagina caching Activeer page caching, configureer OPcache op de juiste manier en stroomlijn vervolgens database queries. Page caching levert HTML, reduceert databasebelasting tot nul en vlakt belastingspieken af. OPcache compileert PHP één keer, wat betekent dat PHP-FPM minder werk hoeft te doen en TTFB wordt verminderd. Een objectgebaseerde cache met Redis is alleen de moeite waard als de serverbronnen royaal beschikbaar zijn en de applicatielogica weinig schrijftoegang per pagina genereert. Met deze volgorde elimineer ik knelpunten bij de bron en houd ik het aantal bewegende delen beheersbaar, in plaats van een fragiele tijdelijke opslag te behouden.

Maatregel Belangrijkste voordelen Risico/specialiteit
Pagina caching (statische HTML) Zeer laag TTFB, nauwelijks DB-belasting Inhoud moet specifiek worden bijgewerkt wanneer er wijzigingen worden aangebracht
OPcache (PHP bytecode) Minder CPU-tijd per Verzoek Vereist consistente inzet en opwarmstrategie
Redis Object Cache Snelle toegang tot frequente objecten Helpt alleen bij treffers; vreet RAM, heeft een schoon toetsontwerp nodig
MySQL Query Cache Theoretisch minder query's uitvoeren Veel moeite met ongeldig verklaren, risico op inconsistentie, extra overhead

Praktische handleiding: Alternatieven deactiveren en testen

Ik begin met MySQL en schakel de query cache op systeemniveau uit door de configuratie te wijzigen in query_cache_type op 0 en query_cache_grootte op 0 ingesteld. Daarna ruim ik WordPress op: Als een drop-in of een constante object caching forceert, deactiveer ik het als test met define('WP_CACHE', false);. Vervolgens gebruik ik tools zoals Query Monitor, Blackfire of eenvoudige statistieken (TTFB, query's/requests, CPU) om de werkelijke impact per pagina te meten. Pas als page caching is ingesteld en PHP/OPcache goed draaien, beoordeel ik specifiek of een kleine Redis-laag de belasting op individuele hotspots verlicht. Deze volgorde geeft me reproduceerbare resultaten en zorgt ervoor dat Stabiliteit, in plaats van te hopen op een toevalstreffer.

Concrete configuraties die hun waarde hebben bewezen

Een paar standaardinstellingen waarmee ik regelmatig stabiele winsten behaal (altijd valideren op je eigen systeem):

  • MySQL/MariaDB: 
    [mysqld]
query_cache_type=0
query_cache_grootte=0
innodb_buffer_pool_size=60-70%_vom_RAM
innodb_flush_log_at_trx_commit=1
langzame_vraag_log=1
lange_vraag_tijd=0.2
log_query's_niet_gebruiken_indexen=1
    De bufferpool draagt de grootste belasting. Ik laat het langzame logboek aan ontwikkelaars zien en verwijder systematisch N+1 en SELECT * patronen.
  • OPcache: 
    opcache.enable=1
opcache.geheugen_verbruik=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=100000
opcache.validate_timestamps=1
opcache.revalidate_freq=60
; JIT voor klassieke WordPress stacks liever uit:
opcache.jit=0
    Een consistente implementatie (bijv. atomic symlinks) en een warming-up na releases zijn belangrijk.
  • PHP-FPM: 
    pm=dynamisch
pm.max_children=
pm.max_requests=500-1000
proces_idle_timeout=10s
    Dit dempt lekken en fragmentatie zonder koude starts te veroorzaken.
  • Redis (indien gebruikt): 
    maxmemory 
maxmemory-policy vluchtig-lru
tcp-backlog 511
; lokaal geprefereerd via UNIX socket voor minimale latentie
    Ik accepteer Redis alleen lokaal of in dezelfde AZ/host - over langzame netwerken wordt het al snel een latentieversterker.

Houd de database schoon: Indexen, query's, plugins

Voordat ik caches stapel, optimaliseer ik queries en Indices, omdat de grootste tijdsbesparing voortkomt uit goed datawerk. Te lange JOIN's, SELECT *, ontbrekende WHERE-voorwaarden en sorteren zonder index kosten meer tijd dan welke cache dan ook kan besparen. Ik controleer regelmatig plugins die veel opties opslaan in wp_options zonder autoload strategie en verwijder overbodige extensies. Een doelgericht hulpmiddel kan zijn om je eigen SQL-patronen te bekijken en te stroomlijnen - een inleiding wordt gegeven door Databasequery's optimaliseren. Met een schone querydiscipline neemt de druk op de server meetbaar af en het veronderstelde voordeel van de WordPress querycache zorgt voor zichzelf omdat er niets meer te verbergen valt.

Hostingfactoren die caching verslaan

Goed CPU-prestaties, snelle NVMe SSD's, voldoende RAM en de nieuwste MySQL-versies maken meer verschil dan een kwetsbare querycache. De configuratie van de webserver speelt ook een grote rol: keep-alive, HTTP/2 of HTTP/3, zinvolle timeouts en een slanke PHP process pool. Ik zorg ervoor dat OPcache ruim bemeten is, zodat de bytecode van de frequente scripts er volledig in past. Tegelijkertijd beperk ik cron jobs en achtergrondtaken die query stormen veroorzaken tijdens piekmomenten. Dit zorgt voor een solide basisperformance waarop ik page caching en gerichte object caching met uiterste precisie kan gebruiken, zonder te verzanden in broze Workarounds te verliezen.

Meetmethoden: hoe ik het effect beoordeel

Ik meet eerst de Basislijn zonder query cache: koude start, warme start, dan 50 tot 200 verzoeken met JMeter of k6. Ik activeer dan specifiek slechts één stelschroef, nooit meerdere tegelijk, en herhaal de belastingstests. Ik registreer statistieken zoals TTFB, P95/P99 latency, queries per request, cache hit rates en CPU/IO waarden. Een echte winst voor mij is wanneer de mediaan en P95 dalen, de foutpercentages dalen en de variantie kleiner wordt. In bijna alle WordPress projecten laat deze methode zien dat de WordPress query cache de variantie verhoogt en de mediane foutmarge verlaagt. Antwoordwaarde verslechterd.

Draaiboek voor tuning: Drempels en controles

  • RaakpercentageOnder ~60% object cache hits op productief verkeer is het zelden de moeite waard. Ik deactiveer dan consequent en meet opnieuw.
  • Redis latentie>1 ms mediaan lokaal is te veel. Sub-milliseconden kunnen worden bereikt via UNIX socket en korte pijplijn.
  • DB wachttijdenStijgt Draden_lopen aanzienlijk toeneemt onder belasting, controleer ik eerst indices/queries - zet de cache niet aan.
  • variantieEen dalende P95 is voor mij belangrijker dan een cosmetisch betere mediaanstatistiek.
  • InvalidatiesBij elke inhouds- of prijsupdate zie ik hoeveel sleutels er worden verwijderd. Brede verwijderingen zijn een antipatroon.
  • OpwarmingNa deploys/page purges warm ik kritieke routes (startpagina, categorie, kassa) automatisch voor.

Compatibiliteit en risico's met plugins

Sommige extensies overschrijven cachingsleutels, wissen transiënten te vroeg of negeren noodzakelijke cachingsleutels. Haken, wat leidt tot verweesde entries. Problemen worden zichtbaarder in multisite-omgevingen omdat er meer schrijfgebeurtenissen parallel plaatsvinden en ongeldigmaking vaker voorkomt. E-commerce workflows met dynamische prijzen, vouchers en winkelmandfragmenten zijn bijzonder gevoelig: zelfs een vertraging van een paar milliseconden kan de checkout-metriek doen kantelen. Daarom isoleer ik cachingproblemen door plugins geleidelijk te deactiveren en op duidelijke meetpunten te controleren. Als een add-on de query cache nodig heeft, doe ik het zonder en kies ik voor een oplossing die zonder kwetsbare Tussenlaag werkt netjes.

Operationele beveiliging: rollback en onderhoud

Ik houd cachingwijzigingen rollbackbaar. Dit betekent: feature flags voor object/pagina cache, aparte configuratiebestanden en een checklist voor noodgevallen. Als er iets fout gaat onder belasting, trek ik eerst de query/object cache eruit en laat ik de pagina cache + OPcache werken. Daarna:

  1. Gericht spoelen in plaats van globaal: Verwijder alleen aangetaste sleutels, leeg niet het hele Redis.
  2. WP-CLI gebruiken: 
    wp cache spoelen
wp tijdelijk verwijderen --all
    Sla de statistieken vooraf op en meet dan opnieuw.
  3. Houtblokken roteren en trage query log in plaats van de cachecontrole te draaien.

Korte samenvatting: Wat ik inhuur en waarom

Ik schakel de WordPress query cache uit vanwege ongeldigheid, Latency en inconsistentie de theoretische winst opeten. In plaats daarvan vertrouw ik op page caching, OPcache en schoon databasewerk dat consistent en zonder verrassingen levert. Ik gebruik Redis selectief als er een duidelijke hotspot is en er voldoende RAM beschikbaar is. Als je objectief meet, merk je het al snel: goed gestructureerde query's, sterke hostresources en HTML-caching zorgen voor de rustige, snelle reacties die elke site nodig heeft. Op deze manier houd ik de prestaties voorspelbaar, bespaar ik serverkosten in euro's en voorkom ik foutpatronen die met geen enkele querycache betrouwbaar kunnen worden onderschept.

Huidige artikelen