WordPress Object Cache Hit Rate: betekenis en zinvolle streefwaarden

Wat de WordPress-objectcache opslaat

De WordPress-objectcache slaat gegevens op onder een sleutel en binnen een groep. Als WordPress dezelfde waarde opnieuw opvraagt, kan het deze uit de cache halen in plaats van de onderliggende bewerking opnieuw uit te voeren. Hieronder vallen bijvoorbeeld gegevens die anders uit de database zouden moeten worden gelezen of opnieuw zouden moeten worden berekend.

De ingebouwde Core-implementatie is standaard aanvraaggebonden: De cache bewaart de gegevens gedurende één enkel verzoek. Een latere paginabezoek krijgt daardoor niet automatisch toegang tot de eerder opgeslagen waarden. Toch kan de cache al binnen één verzoek herhaalde verzoeken voorkomen.

Een drop-in kan de Core-implementatie vervangen door een persistente objectcache vervangen. Dan kunnen relevante gegevens ook na afloop van afzonderlijke verzoeken behouden blijven. Redis is een mogelijke backend-optie, maar geen vereiste voor WordPress; ook andere backend-oplossingen zijn mogelijk. Zelfs met een persistente drop-in kunnen bepaalde groepen nog steeds alleen voor het huidige verzoek gelden.

Transiënten zijn een andere manier om gegevens op te slaan die slechts tijdelijk nodig zijn. Met een persistente objectcache kunnen ze daar worden opgeslagen, in plaats van – zoals gebruikelijk – in de database. Hun geldigheidsduur duidt niet op een gegarandeerde minimale beschikbaarheid: een waarde kan eerder verdwijnen. Applicatiecode moet er daarom rekening mee houden dat een transient ontbreekt en moet de waarde indien nodig opnieuw kunnen genereren.

Voor de latere beoordeling van een trefpercentage is dit onderscheid van cruciaal belang: toegang tot de lokale cache tijdens een verzoek en toegang tot een externe backend zijn niet noodzakelijkerwijs dezelfde maatstaf. Controleer daarom eerst welke implementatie daadwerkelijk wordt gebruikt en welke gegevens deze persistent verwerkt.

Het verschil tussen objectcache en paginacache

Wanneer een pagina wordt opgeroepen, kan een Pagina cache een reeds gegenereerde paginarespons terugsturen. Als het verzoek daar wordt beantwoord, hoeft het niet hetzelfde WordPress-toepassingspad te doorlopen als een niet-gecachet verzoek. De objectcache werkt daarentegen binnen de toepassing met afzonderlijke gecachete gegevens, niet met de volledige paginarespons.

Stel je een openbaar toegankelijke artikelpagina voor: als het antwoord in de paginacache staat, kan het direct worden weergegeven. Moet WordPress de pagina daarentegen genereren, dan kan de objectcache helpen bij herhaalde gegevensopvragingen. Welk werk hierdoor daadwerkelijk wordt bespaard, hangt af van het verzoek, de opgeslagen gegevens en de betreffende implementatie.

Dit heeft gevolgen voor de interpretatie: een goede objectcache-ratio geeft alleen een beeld van de geregistreerde cachetoegangen. Het zegt niet direct hoeveel bezoekers al een kant-en-klaar antwoord uit de paginacache ontvangen of hoe snel de gehele website reageert. Bij intensieve paginacaching kan het nut van de objectcache vooral zichtbaar worden bij de resterende WordPress-verzoeken.

Ook de browser- en opcode-cache vervullen andere taken. De browsercache houdt bronnen bij de bezoeker beschikbaar; een PHP-opcode-cache slaat gecompileerde PHP-code op. Beide vervangen noch de opslag van afzonderlijke applicatiegegevens in de objectcache, noch de levering van een volledig antwoord vanuit een paginacache.

De constante WP_CACHE Dit alleen is niet voldoende om een Redis-objectcache te activeren. Voor een persistente objectcache heb je een geschikte implementatie nodig en de bijbehorende configuratie. Een aanvullend voorbeeld van de interactie tussen verschillende niveaus vind je in het artikel over de AccelerateWP Cache Engine.

Wat hits en misses ons vertellen

A Raak is het geval wanneer een gezochte vermelding op het betreffende cache-niveau wordt gevonden. Een Juffrouw betekent dat hij daar niet wordt gevonden. Het trefpercentage berekent de verhouding tussen het aantal treffers en het totale aantal getelde treffers en missers: treffers / (treffers + missers) × 100. Als er geen treffers of missers zijn, is het percentage voor deze periode niet gedefinieerd.

Een fout is niet automatisch een technische fout. Bij de eerste toegang kan een vermelding nog ontbreken; ook na het verstrijken van de geldigheidsduur moet deze eventueel opnieuw worden opgevraagd of aangemaakt. Het is van doorslaggevend belang welke gevolgen dergelijke mislukte pogingen hebben voor het concrete proces en of het überhaupt zinvol is om de toegang te herhalen.

De Core-methode van WordPress telt in haar eigen implementatie cache-hits en mislukte pogingen. Een drop-in kan deze implementatie echter vervangen. Daarom kan uit de telwijze van de core niet met zekerheid worden afgeleid wat een plug-in registreert: controleer voor de gebruikte versie welke bezoeken en welke periode de statistieken omvatten.

Redis meldt met keyspace_hits en keyspace_misses succesvolle of mislukte key-lookups in de Redis-keyspace. Ook een mislukte EXISTS-Een oproep kan als een fout worden geteld. Deze Redis-hitpercentage is daarom niet automatisch gelijk te stellen aan een WordPress- of plug-in-quotum.

Als een Redis-instantie door meerdere websites of applicaties wordt gebruikt, kunnen de tellers van die instantie de bezoekersaantallen van al die websites of applicaties gezamenlijk weergeven. Een globale quota kan dan zonder geschikte, afzonderlijke telemetrie niet op betrouwbare wijze aan één enkele WordPress-website worden toegewezen. Bij elke vergelijking moet je daarom vastleggen welk niveau en welke instantie de cijfers eigenlijk beschrijven.

Controleer zorgvuldig het meetbereik en de toegankelijkheid

Controleer vóór de meting welke objectcache-implementatie WordPress gebruikt. Als WP-CLI beschikbaar is en je toegang hebt tot de WordPress-map, kun je daar een leesbare inventarisatie starten met de volgende opdracht:

wp cache type

Het resultaat helpt bij het beoordelen van de implementatie, maar bewijst niet dat elke relevante toegang permanent wordt opgeslagen. WordPress staat toe dat een drop-in de core-cache vervangt; tegelijkertijd hoeven afzonderlijke groepen niet permanent te zijn. Noteer daarom ook de gebruikte drop-in of plug-in en de versie ervan.

Controleer in de documentatie van de betreffende versie welke toegangen onder de weergegeven hits en misses vallen en over welke periode deze worden geteld. Een plug-in-quotum kan alleen zinvol met een andere kengetallen worden vergeleken als het meetbereik en de telwijze bekend zijn. Het is met name belangrijk of de weergave slechts één verzoek of een langere periode beschrijft.

Voor Redis kun je, mits je over een verbinding en de juiste rechten beschikt, in een Redis-CLI-sessie de statistieken en opslaginformatie opvragen (alleen voor leesdoeleinden). De volgende commando’s bevatten bewust geen inloggegevens:

INFO stats
INFO memory

Leg de Meetbereik: Welke instantie of knooppunten zijn opgevraagd, en welke andere websites of applicaties maken er gebruik van? Globale Redis-tellers kunnen bij gezamenlijk gebruik niet zonder meer aan één enkele website worden toegewezen. Controleer de uitvoer op gevoelige bedrijfsinformatie voordat je deze doorgeeft; voor deze inventarisatie is noch een flush, noch een belastingstest nodig.

Als je geen toegang hebt tot de Redis-CLI, vraag dan je hostingprovider naar de beschikbare statistieken en hun toepassingsgebied. Ook een dashboard vormt alleen een bruikbare basis als duidelijk is of het dezelfde instantie, afzonderlijke knooppunten of reeds geaggregeerde waarden weergeeft.

De Redis-hitrate per interval berekenen

Redis-statistieken zijn tellerstanden, geen definitieve conclusie over een bepaalde meetperiode. Lees voor een intervalanalyse de waarden voor keyspace_hits en keyspace_misses aan het begin en aan het einde van hetzelfde vastgestelde tijdsbestek van dezelfde instantie. Noteer beide tijdstippen en de bijbehorende instantie, zodat de metingen met elkaar overeenkomen.

Trek vervolgens voor elke teller de beginwaarde af van de eindwaarde. De Interval-hit-percentage luidt: ΔHits / (ΔHits + ΔMisses) × 100. Het teken Δ staat voor het betreffende verschil. Als beide verschillen nul zijn, zijn er in dit venster geen lookups geteld; het percentage is dan niet gedefinieerd, in plaats van nul procent te bedragen.

Een illustratief rekenvoorbeeld, geen meting: als het aantal hits met 900 stijgt en het aantal misses met 100, komt dat neer op 90 procent bij in totaal 1.000 getelde lookups. Dit betekent noch dat pagina’s 90 procent sneller zijn, noch dat er precies 900 database-opvragingen zijn bespaard. Redis telt key-lookups; het belang daarvan voor de toepassing hangt af van de betreffende toegang.

Als een van de tellers tussen de metingen daalt, is het eenvoudige verschil over deze breuk niet geldig. Dit kan het gevolg zijn van een herstart of het resetten van statistieken. Begin het meetvenster opnieuw of verdeel het op basis van betrouwbare bedrijfsgegevens op het breekpunt, in plaats van een negatieve waarde in de formule te gebruiken.

Als er meerdere knooppunten zijn, bereken je eerst voor elk relevant knooppunt de verschillen over dezelfde periode. Tel vervolgens de hits en misses apart bij elkaar op en bereken daaruit het totale percentage. Een ongewogen gemiddelde van de afzonderlijke percentages behandelt een knooppunt met weinig lookups anderszins op dezelfde manier als een knooppunt met veel lookups; dit kan het totaalbeeld aanzienlijk vertekenen.

Noteer daarbij welke knooppunten daadwerkelijk zijn meegenomen en welke rol ze in de omgeving spelen. Een op deze manier berekend totaalcijfer geeft alleen een beeld van de geselecteerde tellers en hun gebruikers; het wordt niet louter bepaald door de aggregatie tot een specifiek WordPress Object Cache-quotum.

Meetrapport en Redis-statistieken

Naast hits en misses helpen ook andere Redis-tellers bij de interpretatie. Ook hier zijn verschillen binnen de gekozen periode veelzeggender dan op zichzelf staande totaalcijfers. De volgende tabel maakt een onderscheid tussen de betekenis van de waarden en conclusies die niet uitsluitend op deze waarden zijn gebaseerd.

Een stijging van expired_keys kan aanleiding zijn om de levensduur en het gebruikspatroon nader te bekijken. Het laat echter niet zien of een item kort na het verstrijken van de geldigheidsduur opnieuw nodig was. Evenzo is evicted_keys te beschouwen in de context van de geconfigureerde opslaglimiet en verdringingsstrategie, in plaats van daaruit meteen een uitbreiding van de opslagcapaciteit af te leiden.

Een bruikbaar Meetrapport Vermeld het begin en einde van het tijdvenster, de instantie of het knooppunt, de twee tellerverschillen, hun som en de berekende verhouding. Geef aan of de instantie gezamenlijk wordt gebruikt en of er tijdens het venster een herstart of een reset heeft plaatsgevonden. Zo blijven de metingen later traceerbaar.

Registreer tegelijkertijd het betreffende verzoektype en een daarvoor geschikte latentie-indicator, evenals de databasebelasting en het foutenpercentage. Maak bijvoorbeeld onderscheid tussen openbare paginaweergaven en verzoeken van ingelogde gebruikers, indien daarvoor geschikte gegevens beschikbaar zijn. Het Redis-quotum alleen geeft niet aan welk van deze verzoektypes van een treffer heeft geprofiteerd.

Met het oog op een latere vergelijking moeten de periode, de knooppunten en de samenstelling van de verzoeken zo veel mogelijk op elkaar lijken. Noteer bovendien relevante wijzigingen en waarneembare opwarmfasen. Wanneer er gegevens ontbreken of wanneer een gedeelde instantie geen toewijzing toelaat, moet deze beperking in het verslag worden vermeld in plaats van in een schijnbaar nauwkeurige conclusie.

Koude start, webshop en statische website

Na een herstart of implementatie kunnen de benodigde vermeldingen aanvankelijk ontbreken. Dergelijke missers zijn te verwachten tijdens het vullen van de cache; bij herhaalde toegangen kan het percentage treffers vervolgens stijgen. Waarden uit de Koude en warme fase moet je dit apart bekijken, zodat een lang gemiddelde noch de opstartkosten, noch het latere verloop verhult.

Bij een webshop of een gedeelte waarvoor je moet inloggen, zijn dynamische verzoeken bijzonder interessant: een paginacache beantwoordt niet per se elk verzoek om het winkelmandje of het account weer te geven. Vergelijk daarom zoveel mogelijk vergelijkbare verzoektypes en let naast het percentage ook op hun responstijden en de databasebelasting. Een hoge Redis-hitrate geeft op zichzelf niet aan of het winkelmandje snel en inhoudelijk correct wordt weergegeven.

Bij een overwegend statische website kan daarentegen een groot deel van de paginaweergaven al uit de paginacache komen. Een persistente objectcache heeft daar vooral invloed op de verzoeken die WordPress daadwerkelijk verwerkt. Beoordeel daarom afzonderlijk of deze resterende verzoeken hiervan profiteren en of het effect zich op de gehele website uit.

Als je Redis samen met andere websites of applicaties gebruikt, worden de bezoeken daarvan ook meegeteld in de instantieteller. Zonder geschikte, afzonderlijke telemetrie kan de globale quota niet op betrouwbare wijze aan één enkele website worden toegewezen. Documenteer ook welke knooppunten worden meegeteld: een verandering in de quota kan anders net zo goed het gevolg zijn van ander gebruik of een gewijzigd meetbereik.

Opvallende waarden en fouten onderzoeken

Een laag percentage is in eerste instantie een observatie, geen diagnose. Veel eerste verzoeken, korte levensduur of een verdeling van verzoeken waarbij sleutels zelden worden hergebruikt, kunnen mogelijke verklaringen zijn. Controleer of de samenstelling van de verzoeken of het meetvenster is veranderd voordat je de geheugen- of cache-instellingen aanpast.

De tellers expired_keys en evicted_keys geven aanvullende aanwijzingen: de eerste telt verlopen sleutels, de tweede telt sleutels die vanwege de opslaglimiet zijn verdrongen. Hun verschillen zijn specifiek voor de Redis-instantie en moeten aansluiten bij de configuratie en het gebruik. Een groot aantal verlopen sleutels wijst niet op een verkeerd gekozen TTL, noch op het feit dat een langere levensduur zinvol is; dit kan de actualiteit van opgeslagen gegevens juist verslechteren.

Voor eigen uitbreidingen geldt bij wp_cache_get de parameter $found belangrijk: hij maakt onderscheid tussen een gevonden en een opgeslagen waarde false van een niet-gevonden vermelding. Voordat je groepsgerichte acties uitvoert, moet je met wp_cache_supports controleer of de betreffende backend de gewenste functie ondersteunt. Een vervangende drop-in kan afwijken van de core-implementatie.

Waarschuwing: Een ondoordachte cache-flush kan meer records of toepassingen beïnvloeden dan de bedoeling was en de volgende meting door een koude start vertekenen. Controleer het toepassingsgebied en zorg voor goedkeuring voordat je verwijderingsacties uitvoert. Aanvullende aandachtspunten voor de Problemen oplossen bij een trage WordPress-objectcache helpen om ook eventuele cache-overhead in het onderzoek mee te nemen.

Zelf zinvolle streefwaarden vaststellen

Een universeel minimumquotum van 90 procent is geen haalbare technische eis. Het is zinvoller om een locatiespecifiek streefbereik, die aansluit bij de verwachte verdeling van de bezoeken en het nut voor de toepassing. Redis raadt aan om het waargenomen percentage te beoordelen in de context van het betreffende bezoekpatroon; een percentage op zich zegt nog niets over de prestaties van WordPress.

Voer eerst een representatieve basismeting uit, met vermelding van de periode, het meetbereik, het aantal bezoeken en het quotum. Leg daarbij de responstijden van belangrijke verzoektypes, de databasebelasting en het foutenpercentage vast. Geef koude starts apart aan en houd rekening met typische verschillen tussen periodes met weinig en veel verkeer, in plaats van een toevallig gunstig tijdvak als normale toestand te beschouwen.

Plan vervolgens een concrete wijziging en test deze na goedkeuring indien mogelijk eerst in een geschikte testomgeving. Vergelijk daarna vergelijkbare tijdsperioden en combinaties van verzoeken: veranderen de quota en het aantal lookups, maar ook de latentie of de databasebelasting? Zo kun je het effect beter onderscheiden van een loutere verschuiving in het aantal verzoeken.

Zelfs een hoog percentage kan enkele, bijzonder dure fouten verhullen. Omgekeerd hoeft een gematigd percentage geen probleem te zijn, mits relevante verzoeken snel en correct worden beantwoord. Extra operationele kosten voor Redis of een andere persistente backend worden niet automatisch gerechtvaardigd door alleen een betere score; houd rekening met hostingondersteuning, kosten en mogelijke uitvalscenario's.