WordPress-objektcache-hitrate: Betydning og fornuftige målværdier

Hvad WordPress-objektcachen gemmer

Der WordPress-objektcache gemmer data under en nøgle og inden for en gruppe. Hvis WordPress anmoder om den samme værdi igen, kan det hente den fra cachen i stedet for at udføre det underliggende arbejde på ny. Dette omfatter for eksempel data, der ellers skulle læses fra databasen eller genberegnes.

Den indbyggede Core-implementering er som standard anmodningsbaseret: Den gemmer sine poster i løbet af en enkelt anmodning. Et senere sidebesøg får derfor ikke automatisk adgang til de tidligere gemte værdier. Alligevel kan cachen undgå gentagne adgangsforespørgsler allerede inden for en enkelt anmodning.

En drop-in kan erstatte Core-implementeringen med en persistent objektcache erstatte. På den måde kan relevante poster bevares ud over de enkelte anmodninger. Redis er en mulig backend-løsning, men ikke en forudsætning for WordPress; andre backend-løsninger er også mulige. Selv med en persistent drop-in kan visse grupper fortsat kun gælde for den aktuelle anmodning.

Transienter er en anden mulighed for at gemme data, der kun er nødvendige i en begrænset periode. Med en persistent objektcache kan de gemmes der, i stedet for som normalt i databasen. Deres udløbstid angiver ikke en garanteret minimums tilgængelighed: En værdi kan forsvinde før tid. Applikationskoden skal derfor tage højde for, at en transient kan mangle, og være i stand til at gendanne værdien, hvis det er nødvendigt.

Denne skelnen er afgørende for den senere vurdering af en hitrate: Adgang til den lokale cache under en anmodning og adgang til et eksternt backend er ikke nødvendigvis det samme måleparameter. Kontroller derfor først, hvilken implementering der rent faktisk anvendes, og hvilke data den lagrer permanent.

Forskellen mellem objektcache og sidecache

Når en side åbnes, kan en Side-cache levere et allerede genereret sidesvar. Hvis forespørgslen besvares der, behøver den ikke at gennemløbe den samme WordPress-applikationssti som en forespørgsel, der ikke er gemt i cachen. Objektcachen arbejder derimod inden for applikationen med enkelte cachelagrede data, ikke med det fulde sidesvar.

Forestil dig en offentligt tilgængelig artikelside: Hvis svaret findes i sidecachen, kan den leveres med det samme. Skal WordPress derimod generere siden, kan objektcachen hjælpe ved gentagne dataadgange. Hvilket arbejde der dermed faktisk spares, afhænger af forespørgslen, de gemte poster og den pågældende implementering.

Det har konsekvenser for fortolkningen: En god objektcache-procent beskriver kun de registrerede cache-adgange. Den siger ikke umiddelbart, hvor mange besøgende der allerede modtager et færdigt svar fra sidecachen, eller hvor hurtigt hele hjemmesiden reagerer. Ved intensiv sidecaching kan fordelene ved objektcachen især blive synlige i de resterende WordPress-anmodninger.

Også browser- og opcode-cachen udfører andre opgaver. Browser-cachen gemmer ressourcer hos den besøgende; en PHP-opcode-cache gemmer kompileret PHP-kode. Ingen af dem erstatter hverken lagringen af individuelle applikationsdata i objektcachen eller leveringen af et komplet svar fra en sidecache.

Konstanten WP_CACHE Dette aktiverer ikke i sig selv en Redis-objektcache. For at få en persistent objektcache skal du have en passende implementering og den tilhørende konfiguration. Et supplerende eksempel på samspillet mellem flere niveauer finder du i indlægget om AccelerateWP Cache Engine.

Hvad succeser og fiaskoer fortæller os

En Hit foreligger, når en efterspurgt post findes på det pågældende cache-niveau. En Frøken betyder, at den ikke findes der. Hitraten angiver forholdet mellem antallet af hits og det samlede antal registrerede hits og fejlforsøg: Hits / (Hits + Fejl) × 100. Hvis der hverken er hits eller fejl, er raten for denne periode ikke defineret.

En fejl er ikke nødvendigvis en teknisk fejl. Ved den første adgang kan en post stadig mangle; selv efter udløbet skal den i givet fald hentes eller oprettes på ny. Det afgørende er, hvilke konsekvenser sådanne mislykkede forsøg har for den konkrete proces, og om det overhovedet giver mening at gentage adgangen.

WordPress’ Core-metode tæller i sin egen implementering cache-hits og fejlforsøg. En drop-in kan dog erstatte denne implementering. Derfor kan man ikke med sikkerhed udlede af kernens tællingsmetode, hvad en plugin-visning registrerer: Kontroller for den anvendte version, hvilke adgangshændelser og hvilket tidsrum dens nøgletal omfatter.

Redis melder med keyspace_hits og keyspace_misses vellykkede henholdsvis mislykkede nøgleopslag i Redis-nøgleområdet. Også et mislykket EXISTS-En sådan handling kan tælle som en fejl. Denne Redis-træffeprocent kan derfor ikke automatisk sidestilles med en WordPress- eller plugin-kvote.

Hvis en Redis-instans betjener flere hjemmesider eller applikationer, kan dens tællere samlet afspejle deres besøgstal. En global kvote kan derfor ikke pålideligt tilskrives en enkelt WordPress-hjemmeside uden passende, separat telemetri. Ved enhver sammenligning bør du derfor notere, hvilket niveau og hvilken instans tallene overhovedet beskriver.

Kontroller måleområdet og adgangen grundigt

Før målingen skal du finde ud af, hvilken objektcache-implementering WordPress bruger. Hvis WP-CLI er tilgængeligt, og du har adgang til WordPress-mappen, kan du starte en læse-opgørelse der med følgende kommando:

wp cache type

Resultatet hjælper med at vurdere implementeringen, men beviser ikke, at alle relevante adgangshændelser gemmes permanent. WordPress tillader, at et drop-in erstatter kerne-cachen; samtidig kan enkelte grupper være ikke-permanente. Notér derfor også det anvendte drop-in eller plugin og dets version.

Tjek i dokumentationen for den konkrete version, hvilke adgangshændelser der indgår i de viste hits og misses, og over hvilket tidsrum de tælles. En plugin-kvote kan kun sammenlignes meningsfuldt med en anden nøgletal, hvis måleområdet og tællingsmetoden er kendt. Det er især vigtigt at vide, om visningen kun beskriver en enkelt anmodning eller et længere tidsvindue.

For Redis kan du, forudsat at der er forbindelse og de nødvendige rettigheder, hente statistik- og hukommelsesoplysninger i en Redis-CLI-session i læsemodus. Følgende kommandoer indeholder bevidst ingen adgangsoplysninger:

INFO stats
INFO memory

Dokumenter Måleområde: Hvilke instanser eller noder er der blevet forespurgt på, og hvilke andre websteder eller applikationer bruger de? Globale Redis-tællere kan ikke umiddelbart tilknyttes et enkelt websted, når de deles. Kontroller udskrifterne for følsomme driftsoplysninger, inden de videregives; hverken en flush eller en belastningstest er nødvendig for denne statusopgørelse.

Hvis du ikke har adgang til Redis-CLI’en, skal du spørge din hostingudbyder om de tilgængelige målinger og deres anvendelsesområde. Et dashboard er kun et brugbart grundlag, hvis det fremgår klart, om det viser den samme instans, enkelte noder eller allerede aggregerede værdier.

Beregning af Redis-hitrate i et interval

Redis-statistikker er tællertal, ikke en færdig konklusion om et bestemt måleinterval. For at foretage en intervalanalyse skal du læse værdierne for keyspace_hits og keyspace_misses ved begyndelsen og slutningen af det samme fastlagte tidsvindue fra den samme instans. Notér begge tidspunkter og den tilhørende instans, så aflæsningerne stemmer overens.

Træk derefter startværdien fra slutværdien for hver tæller. Den Interval-hit-rate er: ΔHits / (ΔHits + ΔMisses) × 100. Tegnet Δ angiver den pågældende forskel. Hvis begge forskelle er nul, blev der ikke registreret nogen opslag i dette vindue; i så fald er andelen ikke defineret i stedet for at være nul procent.

Et illustrativt regneeksempel, ikke en måling: Hvis antallet af hits stiger med 900 og antallet af misses med 100, giver det 90 procent ud af i alt 1.000 tællede opslag. Det betyder hverken, at siderne er 90 procent hurtigere, eller at der er sparet nøjagtigt 900 databaseforespørgsler. Redis tæller nøgleopslag; deres betydning for applikationen afhænger af den pågældende adgang.

Hvis en af tællerne falder mellem aflæsningerne, er den simple forskel ved denne brøk ikke gyldig. Dette kan skyldes en genstart eller en nulstilling af statistikkerne. Start målevinduet forfra, eller opdel det ved bruddet på baggrund af pålidelige driftsdata, i stedet for at indsætte en negativ værdi i formlen.

Hvis der er flere knudepunkter, beregner du først forskellene for hvert relevant knudepunkt over den samme periode. Derefter lægger du hits og misses sammen hver for sig og udleder den samlede andel ud fra dette. Et uvægtet gennemsnit af de enkelte procentværdier behandler en node med få opslag på samme måde som en med mange; det kan forvride det samlede billede betydeligt.

Notér dig, hvilke noder der rent faktisk indgår, og hvilken rolle de spiller i miljøet. En samlet rate, der er beregnet på denne måde, beskriver kun de udvalgte tællere og deres brugere; den bliver ikke alene til en specifik WordPress-Object-Cache-kvote ved sammenlægning.

Måleprotokol og Redis-nøgletal

Ud over hits og misses er der yderligere Redis-tællere, der hjælper med at sætte tingene i perspektiv. Også her er forskelle inden for den valgte periode mere sigende end isolerede samletal. Den følgende tabel skelner mellem værdiernes betydning og de konklusioner, som de ikke alene kan underbygge.

En stigning på expired_keys kan være en anledning til at se nærmere på levetider og adgangsmønstre. Det viser dog ikke, om en post blev brugt igen kort efter, at den var udløbet. Ligeledes er evicted_keys skal ses i sammenhæng med den konfigurerede lagergrænse og fortrængningsstrategien, i stedet for straks at konkludere, at lagerkapaciteten skal øges.

Et brugbart Måleprotokol Angiv start- og slutpunktet for tidsvinduet, instansen henholdsvis noden, de to tællerdifferencer, deres sum og det beregnede forholdstal. Angiv desuden, om instansen deles, og om der er kendskab til en genstart eller en nulstilling i løbet af tidsvinduet. På den måde forbliver målingerne sporbare senere.

Registrer samtidig den pågældende anmodningstype og et passende latenstalsindikator samt databasebelastning og fejlrate. Adskil f.eks. offentlige sidevisninger fra anmodninger fra indloggede brugere, hvis der foreligger relevante data herom. Redis-kvoten alene afslører ikke, hvilken af disse anmodningstyper der har draget fordel af et hit.

For at kunne foretage en senere sammenligning bør tidsperioden, knudepunkterne og sammensætningen af anmodninger være så ens som muligt. Notér desuden relevante ændringer og mærkbare opvarmningsfaser. Hvor der mangler data, eller hvor en fælles instans ikke tillader en sammenkobling, skal denne begrænsning fremgå af protokollen i stedet for at indgå i en tilsyneladende præcis konklusion.

Koldstart, webshop og statisk hjemmeside

Efter en genstart eller en implementering kan de nødvendige poster i første omgang mangle. Sådanne mangler er forventelige, når cachen fyldes op; ved gentagne adgangsforespørgsler kan hitprocenten efterfølgende stige. Værdier fra Kold- og varmfase bør du betragte dem hver for sig, så et langt gennemsnit hverken skjuler opstartsomkostningerne eller den senere udvikling.

I forbindelse med en webshop eller et område, hvor brugeren er logget ind, er dynamiske forespørgsler særligt interessante: En sidecache besvarer ikke nødvendigvis hver eneste opkald til indkøbskurven eller kontoen. Sammenlign derfor så vidt muligt lignende anmodningstyper, og vær opmærksom på både hitraten, svartiderne og databasebelastningen. En høj Redis-hitrate viser i sig selv ikke, om indkøbskurven vises hurtigt og med korrekt indhold.

På et overvejende statisk websted kan en stor del af sidevisningerne derimod allerede komme fra sidecachen. En vedvarende objektcache påvirker her især de forespørgsler, som WordPress rent faktisk behandler. Vurder derfor separat, om disse resterende forespørgsler drager fordel heraf, og om effekten slår igennem på hele webstedet.

Hvis du bruger Redis sammen med andre websteder eller applikationer, medregnes deres adgang også i instanstælleren. Uden passende, separat telemetri er det ikke muligt pålideligt at tilskrive den globale kvote til et enkelt websted. Dokumenter også, hvilke noder der er medtaget: En ændring i kvoten kan ellers lige så vel skyldes en anden anvendelse eller et ændret måleområde.

Undersøgelse af afvigende værdier og fejl

En lav andel er i første omgang en observation, ikke en diagnose. Mange første adgangsforespørgsler, korte levetider eller en fordeling af adgangsforespørgsler med nøgler, der sjældent genbruges, kan være mulige forklaringer. Kontroller, om sammensætningen af forespørgslerne eller målevinduet har ændret sig, før du justerer hukommelses- eller cacheindstillingerne.

Tællerne expired_keys og evicted_keys giver yderligere oplysninger: Den første tæller udløbne nøgler, den anden tæller nøgler, der er blevet fortrængt på grund af hukommelsesbegrænsningen. Forskellene mellem dem er specifikke for den pågældende Redis-instans og skal passe til konfigurationen og brugen. Mange udløbne nøgler er hverken tegn på en forkert valgt TTL eller på, at en længere levetid er hensigtsmæssig; det kan forringe aktualiteten af de gemte data.

Ved egne udvidelser skal man wp_cache_get parameteren $found Vigtigt: Den skelner mellem en fundet og en gemt værdi false fra en post, der ikke blev fundet. Inden du udfører grupperelaterede handlinger, bør du med wp_cache_supports Kontroller, om det pågældende backend understøtter den ønskede funktion. En erstatningsløsning kan afvige fra kerneimplementeringen.

Advarsel: En uovervejet cache-flush kan påvirke flere poster eller applikationer end tilsigtet og forvride den næste måling på grund af en koldstart. Afklar rækkevidden og indhent godkendelse, inden du udfører sletningshandlinger. Yderligere udgangspunkter til Fejlfinding ved en langsom WordPress-objektcache hjælpe med at inddrage eventuel cache-overhead i undersøgelsen.

Selv fastlægge fornuftige målværdier

En universel mindstekote på 90 procent er ikke et holdbart teknisk krav. Det giver mere mening at indføre en stedsspecifikt målområde, der passer til den forventede fordeling af adgang og til applikationens formål. Redis anbefaler, at man vurderer den observerede andel i sammenhæng med det pågældende adgangs mønster; en procentdel alene forklarer ikke WordPress-ydeevnen.

Foretag først en repræsentativ indledende måling med tidsperiode, måleområde, antal adgangshændelser og andel. Registrer i den forbindelse svartider for vigtige anmodningstyper, databasebelastning og fejlprocent. Markér koldstarter særskilt, og tag højde for typiske forskelle mellem perioder med lav og høj trafik, i stedet for at betragte et tilfældigt gunstigt tidsvindue som normal tilstand.

Planlæg derefter en konkret ændring, og test den efter godkendelse om muligt først i et passende testmiljø. Sammenlign derefter sammenlignelige tidsperioder og blandinger af forespørgsler: Ændrer kvoten og antallet af opslag sig, men også latenstiden eller databasebelastningen? På den måde kan effekten bedre skelnes fra en ren forskydning af adgangene.

Selv en høj svarprocent kan skjule nogle få, særligt dyre fejl. Omvendt behøver en moderat svarprocent ikke at være et problem, hvis relevante forespørgsler besvares hurtigt og korrekt. Ekstra driftsomkostninger til Redis eller et andet persistent backend er ikke automatisk berettiget alene på grund af en bedre kvote; tag højde for hosting-support, omkostninger og mulige nedbrudsscenarier.