WordPress Object Cache Hit Rate: Betydelse och meningsfulla målvärden

Vad WordPress Object Cache lagrar

Der WordPress-objektcache lagrar data under en nyckel och inom en grupp. Om WordPress begär samma värde igen kan det hämta det från cachen istället för att utföra det underliggande arbetet på nytt. Detta omfattar till exempel data som annars skulle behöva läsas in från databasen eller beräknas på nytt.

Den inbyggda Core-implementeringen är som standard begäranbaserad: Den lagrar sina poster under en enskild begäran. En senare sidvisning får därför inte automatiskt tillgång till de tidigare lagrade värdena. Trots detta kan cachen undvika upprepade åtkomstförsök redan inom ramen för en och samma begäran.

En drop-in kan ersätta Core-implementeringen med en permanent objektcache ersätta. Då kan lämpliga poster bevaras även efter enskilda förfrågningar. Redis är ett möjligt backend-alternativ, men inget krav för WordPress; även andra backend-lösningar är möjliga. Även med en persistent drop-in kan vissa grupper fortfarande endast gälla för den aktuella förfrågan.

Transienter är ett annat sätt att lagra data som endast behövs under en begränsad tid. Med en persistent objektcache kan de lagras där, utan att normalt behöva lagras i databasen. Deras giltighetstid innebär inte någon garanterad minsta tillgänglighet: ett värde kan försvinna tidigare. Applikationskoden måste därför räkna med att en transient kan saknas och kunna återskapa värdet vid behov.

Denna distinktion är avgörande för den senare utvärderingen av träfffrekvensen: En åtkomst till den lokala cachen under en begäran och en åtkomst till ett externt backend är inte nödvändigtvis samma mått. Kontrollera därför först vilken implementering som faktiskt används och vilka data den lagrar permanent.

Skillnaden mellan objektcache och sidcache

När en sida laddas kan en Cache för sidor leverera ett redan genererat sidsvar. Om förfrågan besvaras där behöver den inte gå igenom samma WordPress-applikationsväg som en förfrågan som inte finns i cachen. Objektcachen arbetar däremot inom applikationen med enskilda cachelagrade data, inte med hela sidsvaret.

Föreställ dig en artikelsida som är tillgänglig för allmänheten: Om svaret finns i sidcachen kan sidan levereras direkt. Om WordPress däremot måste generera sidan kan objektcachen underlätta vid upprepade datahämtningar. Hur mycket arbete som faktiskt sparas beror på förfrågan, de lagrade posterna och den aktuella implementeringen.

Detta får konsekvenser för tolkningen: En bra objektcache-kvot beskriver endast de registrerade cache-åtkomsterna. Den säger inte direkt hur många besökare som redan får ett färdigt svar från sidcachen eller hur snabbt hela webbplatsen reagerar. Vid omfattande sidcachelagring kan nyttan med objektcachen framför allt märkas i de återstående WordPress-förfrågningarna.

Även webbläsar- och opkodscachen har andra uppgifter. Webbläsarcachen lagrar resurser hos besökaren, medan en PHP-opkodscache lagrar kompilerad PHP-kod. Ingen av dem ersätter vare sig lagringen av enskilda applikationsdata i objektcachen eller leveransen av ett fullständigt svar från en sidcache.

Konstanten WP_CACHE Detta aktiverar inte i sig någon Redis-objektcache. För en persistent objektcache behöver du en lämplig implementering och en konfiguration som stöds av den. Ett ytterligare exempel på samspelet mellan flera nivåer finns i inlägget om AccelerateWP Cache Engine.

Vad framgångar och misslyckanden säger oss

En Hit gäller när en sökt post hittas på den aktuella cache-nivån. En Fröken betyder att den inte hittas där. Träfffrekvensen beräknas genom att sätta träffarna i förhållande till det totala antalet träffar och missar: Träffar / (Träffar + Missar) × 100. Om det varken finns träffar eller missar är träfffrekvensen för den aktuella tidsperioden inte definierad.

Ett misslyckande innebär inte automatiskt ett tekniskt fel. Vid den första åtkomsten kan en post fortfarande saknas; även efter att den har löpt ut kan den i vissa fall behöva hämtas eller skapas på nytt. Det avgörande är vilka konsekvenser sådana misslyckade försök har för den konkreta processen och om det överhuvudtaget är meningsfullt att upprepa åtkomsterna.

WordPress Core-metoden räknar cacheträffar och misslyckade försök i sin egen implementering. En drop-in kan dock ersätta denna implementering. Därför går det inte att med säkerhet utläsa ur kärnans räknesätt vad en plugin-visning registrerar: Kontrollera för den använda versionen vilka åtkomsthändelser och vilken tidsperiod dess statistik omfattar.

Redis rapporterar med keyspace_hits och keyspace_misses lyckade respektive misslyckade nyckelsökningar i Redis-nyckelutrymmet. Även en misslyckad EXISTS-En sådan uppmaning kan räknas som en miss. Denna Redis träfffrekvens kan därför inte automatiskt likställas med en WordPress- eller plugin-kvot.

Om en Redis-instans används av flera webbplatser eller applikationer kan dess räknare sammanfattningsvis återspegla deras trafik. En global kvot kan då inte på ett tillförlitligt sätt tillskrivas en enskild WordPress-webbplats utan lämplig separat telemetri. Vid varje jämförelse bör du därför notera vilken nivå och vilken instans siffrorna överhuvudtaget avser.

Kontrollera noggrant mätområdet och åtkomsten

Ta reda på vilken objektcache-implementering WordPress använder innan du börjar mäta. Om WP-CLI är tillgängligt och du har åtkomst till WordPress-katalogen kan du starta en läsbar inventering där med följande kommando:

wp cache type

Resultatet hjälper till att klassificera implementeringen, men bevisar inte att varje relevant åtkomst lagras permanent. WordPress tillåter att ett drop-in ersätter kärncachen; samtidigt kan enskilda grupper inte vara permanenta. Notera därför även vilket drop-in eller plugin som används samt dess version.

Kontrollera i dokumentationen för den specifika versionen vilka åtkomsthändelser som ingår i de visade träffarna och missarna samt under vilken tidsperiod de räknas. En plugin-kvot kan endast jämföras meningsfullt med ett annat nyckeltal om mätområdet och räknemetoden är kända. Det är särskilt viktigt att veta om visningen endast avser en enda begäran eller ett längre tidsfönster.

För Redis kan du, förutsatt att du har en anslutning och behörighet, läsa av statistik- och lagringsinformation i en Redis-CLI-session. Följande kommandon innehåller medvetet inga inloggningsuppgifter:

INFO stats
INFO memory

Dokumentera Mätområde: Vilka instanser eller noder har undersökts, och vilka andra webbplatser eller applikationer använder dem? Globala Redis-räknare kan inte utan vidare kopplas till en enskild webbplats när de används gemensamt. Kontrollera utdata för känslig driftsinformation innan den vidarebefordras; varken en tömning eller en belastningstest krävs för denna inventering.

Om du inte har tillgång till Redis-CLI, fråga din webbhotellleverantör om vilka mätvärden som finns tillgängliga och deras omfattning. Även en översiktspanel är bara en användbar utgångspunkt om det står klart om den visar samma instans, enskilda noder eller redan aggregerade värden.

Beräkna Redis-träfffrekvensen för ett intervall

Redis-statistiken består av räknarvärden, inte av färdiga slutsatser om en viss mätperiod. För en intervallanalys bör du läsa av värdena för keyspace_hits och keyspace_misses i början och i slutet av samma tidsintervall från samma instans. Notera båda tidpunkterna och den tillhörande instansen så att avläsningarna stämmer överens.

Därefter subtraherar du ingångsvärdet från utgångsvärdet för varje mätare. Den Intervall-träfffrekvens beräknas enligt följande: ΔHits / (ΔHits + ΔMisses) × 100. Tecknet Δ står för respektive skillnad. Om båda skillnaderna är noll har inga uppslagningar registrerats i detta fönster; kvoten är då odefinierad istället för att uppgå till noll procent.

Ett illustrativt räkneexempel, ingen mätning: Om träffarna ökar med 900 och missarna med 100 blir resultatet 90 procent av totalt 1 000 räknade sökningar. Det betyder varken att sidorna är 90 procent snabbare eller att exakt 900 databasfrågor har sparats in. Redis räknar nyckelsökningar; deras betydelse för applikationen beror på respektive åtkomst.

Om någon av mätarna går tillbaka mellan avläsningarna är den enkla differensen över denna bråkdel inte giltig. Detta kan orsakas av en omstart eller en återställning av statistiken. Börja om mätperioden eller dela upp den vid brytpunkten utifrån tillförlitliga driftsdata, istället för att använda ett negativt värde i formeln.

Om det finns flera noder beräknar du först skillnaderna för varje relevant nod under samma tidsperiod. Summera sedan träffarna och missarna separat och beräkna den totala andelen utifrån dessa. Ett oviktat medelvärde av de enskilda procentvärdena behandlar en nod med få sökningar på samma sätt som en med många; detta kan förvränga helhetsbilden avsevärt.

Notera samtidigt vilka noder som faktiskt ingår och vilken roll de spelar i miljön. En totalhastighet som beräknats på detta sätt beskriver endast de utvalda räknarna och deras användare; den blir inte i sig en specifik WordPress Object Cache-kvot enbart genom aggregeringen.

Mätprotokoll och Redis-nyckeltal

Förutom träffar och missar finns det ytterligare Redis-räknare som underlättar tolkningen. Även här är skillnader inom den valda tidsperioden mer meningsfulla än isolerade totalsiffror. Tabellen nedan skiljer mellan värdenas betydelse och slutsatser som inte kan grundas enbart på dem.

En ökning med expired_keys kan vara ett skäl att närmare granska livslängder och åtkomstmönster. Det visar dock inte om en post behövdes igen strax efter att den hade löpt ut. På samma sätt är evicted_keys att betrakta detta i ljuset av den konfigurerade lagringsgränsen och utskjutningsstrategin, istället för att omedelbart dra slutsatsen att lagringsutrymmet måste utökas.

Ett användbart Mätprotokoll Ange början och slutet på tidsfönstret, instansen respektive noden, de båda räknarskillnaderna, deras summa och den beräknade kvoten. Ange även om instansen används gemensamt och om det är känt att en omstart eller återställning har skett under tidsfönstret. På så sätt går det att spåra mätningarna i efterhand.

Registrera samtidigt den aktuella förfrågningstypen och ett lämpligt latensmått för denna, samt databasbelastning och felfrekvens. Separera till exempel offentliga sidvisningar från förfrågningar från inloggade användare, om lämpliga data finns tillgängliga för detta. Redis-kvoten i sig avslöjar inte vilken av dessa förfrågningstyper som har gynnats av en träff.

För att kunna göra en jämförelse senare bör tidsperiod, noder och sammansättningen av förfrågningar vara så lika som möjligt. Notera dessutom relevanta förändringar och märkbara uppvärmningsfaser. Om data saknas eller om en gemensam instans inte möjliggör någon tilldelning, ska denna begränsning anges i protokollet istället för i en till synes exakt slutsats.

Kallstart, webbutik och statisk webbplats

Efter en omstart eller en distribution kan nödvändiga poster inledningsvis saknas. Sådana brister är att förvänta sig när cachen fylls; vid återkommande åtkomst kan träfffrekvensen därefter öka. Värden från Kall- och varmfas bör du betrakta separat, så att ett långsiktigt genomsnitt inte döljer varken startkostnaderna eller den senare utvecklingen.

I en webbutik eller ett inloggat område är dynamiska förfrågningar särskilt intressanta: en sidcache svarar inte nödvändigtvis på varje förfrågan om varukorgen eller kontot. Jämför därför så likartade förfrågningstyper som möjligt och beakta, förutom andelen, även deras svarstider och databasbelastningen. En hög Redis-träfffrekvens visar i sig inte om varukorgen visas snabbt och med korrekt innehåll.

När det däremot gäller en huvudsakligen statisk webbplats kan en stor del av sidvisningarna redan komma från sidcachen. En persistent objektcache påverkar där framför allt de förfrågningar som WordPress faktiskt bearbetar. Bedöm därför separat om dessa återstående förfrågningar gynnas av detta och om effekten påverkar hela webbplatsen.

Om du använder Redis tillsammans med andra webbplatser eller applikationer inkluderar instansräknarna även deras åtkomst. Utan lämplig separat telemetri går det inte att på ett tillförlitligt sätt tilldela den globala kvoten till en enskild webbplats. Dokumentera även vilka noder som ingår i mätningen: en förändring av kvoten kan annars bero på annan användning eller ett ändrat mätområde.

Undersöka avvikande värden och fel

En låg andel är i första hand en iakttagelse, inte en diagnos. Många första åtkomstförsök, korta livslängder eller en åtkomstfördelning där nycklar sällan återanvänds kan vara möjliga förklaringar. Kontrollera om sammansättningen av förfrågningar eller mätfönstret har förändrats innan du justerar minnes- eller cacheinställningarna.

Räknarna expired_keys och evicted_keys ger ytterligare information: Den första räknar utgångna nycklar, den andra nycklar som har trängts undan på grund av minnesbegränsningen. Skillnaderna mellan dem är specifika för Redis-instansen och måste stämma överens med konfigurationen och användningen. Ett stort antal utgångna nycklar bevisar varken att TTL har valts felaktigt eller att en längre livslängd är lämplig; det kan försämra aktualiteten hos lagrade data.

För egna tillägg gäller följande vid wp_cache_get parametern $found Viktigt: Den skiljer mellan ett värde som har hittats och ett som har sparats false från en post som inte hittades. Innan du utför grupprelaterade åtgärder bör du använda wp_cache_supports Kontrollera om det aktuella backend-systemet stöder den önskade funktionen. En ersättande drop-in-lösning kan skilja sig från kärnimplementeringen.

Varning: En ogenomtänkt cache-rensning kan påverka fler poster eller applikationer än avsett och snedvrida nästa mätning genom en kallstart. Klargör räckvidden och få godkännande innan du utför raderingsåtgärder. Ytterligare utgångspunkter för Felsökning vid en långsam WordPress-objektcache hjälpa till att även beakta eventuell cache-överbelastning i undersökningen.

Själv bestämma rimliga målvärden

En universell minimikvot på 90 procent är inte ett hållbart tekniskt krav. Det är mer meningsfullt med en platsspecifikt målintervall, som stämmer överens med den förväntade åtkomstfördelningen och nyttan för applikationen. Redis rekommenderar att man bedömer den observerade andelen utifrån det aktuella åtkomstmönstret; en procentandel i sig är inte tillräcklig för att förklara WordPress-prestandan.

Gör först en representativ utgångsmätning med tidsperiod, mätområde, antal åtkomstförsök och andel. Notera därvid svarstider för viktiga typer av förfrågningar, databasbelastning och felfrekvens. Markera kallstarter separat och ta hänsyn till typiska skillnader mellan tider med låg respektive hög belastning, istället för att betrakta ett slumpmässigt gynnsamt tidsfönster som normaltillstånd.

Planera därefter en konkret ändring och testa den, om möjligt, först i en lämplig testmiljö efter godkännande. Jämför därefter liknande tidsperioder och olika kombinationer av förfrågningar: Förändras kvoten och antalet sökningar, men också latensen eller databasbelastningen? På så sätt blir det lättare att skilja effekten från en ren förskjutning av åtkomsterna.

Även en hög träfffrekvens kan dölja ett fåtal, särskilt kostsamma missar. Omvänt behöver en måttlig träfffrekvens inte vara något problem om relevanta förfrågningar besvaras snabbt och korrekt. Extra driftskostnader för Redis eller ett annat persistent backend motiveras inte automatiskt enbart av en bättre kvot; ta hänsyn till support från webbhotellet, kostnader och möjliga avbrottsscenarier.