Cache träff ratio: vad det är och hur man får din över 95%
Det är den enda siffran som talar om för dig om ditt CDN faktiskt gör sitt jobb. Vad det betyder, de fem saker som vanligtvis förstör det, och hur man räknar ut vilken som förstör ditt.
Du lägger webbplatsen bakom en CDN, instrumentbrädan har varit uppe i en vecka, och cache träffförhållandet säger 61%. Är det dåligt? Ska du vara orolig? Vad gör du ens göra åt det?
Detta kommer upp mycket, och det ärliga svaret är att 61% är förmodligen dåligt men inte nödvändigtvis - det beror helt på vad din webbplats är. Så låt oss börja med vad numret faktiskt betyder, sedan arbeta genom att diagnostisera din, eftersom fixen är nästan alltid en av fem specifika saker.
Vad betyder numret
Varje begäran som ditt CDN tar emot slutar på ett av två sätt. träff betyder att kanten redan hade en ny kopia och serverade den omedelbart. A fröken betyder att det inte gjorde det, så det frågade ditt ursprung, väntade, vidarebefordrade svaret och behöll en kopia till nästa gång. Cache träffförhållande är träffar dividerat med totala förfrågningar.
En miss är inte bara långsammare för den ena besökaren. Det är en begäran som ditt ursprung måste hantera, bandbredd du betalar för på båda benen och lite mindre utrymme för när trafiken spikar. Multiplicera ett lågt förhållande över miljontals förfrågningar och du kör ett globalt nätverk som en dyr genomgång.
Begäran eller byte?
Värt att veta innan du jämför siffror med någon: vissa instrumentpaneler rapporterar träffförhållande efter begäran, andra av byte som serveras. De kan skilja sig vilt. En webbplats som serverar en enorm uncached video bland en miljon små cachade tillgångar har en utmärkt begäran förhållande och en fruktansvärd byte förhållande. Om din bandbreddsräkning och ditt träffförhållande verkar vara oense, är det vanligtvis varför - kolla vilken du tittar på.
Vad är egentligen ett bra förhållande?
"Över 95%" i titeln är ett rimligt mål för de flesta webbplatser, men det är inte universellt, och att jaga det på fel typ av webbplats är bortkastad ansträngning.
| Webbplatstyp | Realistiskt mål | Varför? |
|---|---|---|
| Statisk webbplats, docs, marknadsföring | 98%+ | Nästan ingenting är personligt |
| Blogg eller utgivare | 95–98% | Långlivade sidor, återanvändning av tunga tillgångar |
| Handla med helsides caching | 85–95% | Varukorg, kassa och konto bypass alltid |
| Endast tillgångszon (bilder, JS, CSS) | 99% | Om det är lägre, är något felaktigt |
| Inloggad app | Varierar vilt | Domare tillgångar och sidor separat |
Två saker följer av bordet. Först, om du kör en butik, inte panik på 88% - en bit av din trafik är kassan och konto sidor som aldrig får cachas, och exklusive dem korrekt är systemet fungerar. För det andra, om du har en separat zon för statiska tillgångar och det är under 99%, det är en äkta felkonfiguration och värt tio minuter av din tid.
Diagnostisera ett lågt förhållande
I grov ordning av hur ofta varje visar sig vara den skyldige:
1. Ditt ursprung berättar CDN att inte cacha
Detta är den vanligaste orsaken på avstånd, och den mest tillfredsställande att fixa eftersom det är vanligtvis en rubrik. Cache-Control: no-store, privateeller max-age=0 berättar kanten för att hoppa över cachelagring helt. Ramverk lägger till dessa som standard oftare än du förväntar dig, särskilt för HTML.
Kontrollera vad ditt ursprung faktiskt skickar, inte vad du tror att det skickar:
curl -sI https://origin.example.com/some-page | grep -iE 'cache-control|set-cookie|vary'2. Frågesträngar fragmenterar cachen
Om /product, /product?utm_source=newsletter och /product?fbclid=abc123 är tre separata cacheposter, en populär sida har tyst blivit flera hundra poster, var och en med en publik på en. Varje del på sociala medier skapar en helt ny cachenyckel som aldrig kommer att begäras igen.
Strip tracking parametrar från cache-nyckeln. De spelar roll för din analys, som läser dem i webbläsaren, och inte alls vilka byte du återvänder till.
3. Cookies på saker som inte behöver dem
A Set-Cookie header på en statisk tillgång gör att CDN behandlar det svaret som personligt och vägrar att lagra det. Din logotyp behöver ingen cookie. Session middleware som körs på varje rutt, inklusive tillgångsrutter, är den vanliga källan.
4. TTLs är för korta
Om innehållet går ut efter 60 sekunder, tillbringar kanten sitt liv med att hämta saker som inte har förändrats. app.a1b2c3.css kan säkert cachas i ett år, eftersom en ny version får ett nytt filnamn. HTML vill vanligtvis ha något kortare, men "kortare" kan fortfarande betyda timmar om du kan rensa på publicera.
5. En Vary header du inte menade att skicka
Den subtila. Vary: User-Agent gör kanten lagra en separat kopia per användaragentsträng, och det finns effektivt obegränsade användaragentsträngar. Din träffförhållande kollapsar och ingenting i din konfiguration ser fel ut. Vary: Accept-Encoding Det är bra och förväntat; nästan allt annat förtjänar en andra titt.
Om du bara gör en sak: sortera dina CDN-loggar efter cachestatus, filtrera till fel och gruppera efter URL. De tjugo bästa missarna kommer att berätta vilken av de fem ovan du har, vanligtvis inom en minut. Att gissa tar längre tid än att titta.
Varför 100% är fel mål
Du kan inte nå 100%, och en webbplats som gjorde skulle vara misstänksam. Cacheposter upphör att gälla. Nytt innehåll måste hämtas en gång. Rensar tömmer cachen med flit. Och en verkligt personlig sida - en vagn, ett konto instrumentbräda - bör missa varje gång, eftersom cachning det skulle vara en bugg och potentiellt en dataläcka.
Numret att titta på är inte det absoluta värdet så mycket som dess form över tiden. Ett förhållande som var 96% och är nu 78% betyder något ändrat: en distribuera ändrade dina rubriker, en kampanj lade till nya frågeparametrar eller någon skickade en cookie på dina tillgångsrutter. Plötslig rörelse är en signal. 91% på en affär är bara tisdag.
Vanliga frågor
Vad är en bra cache hit ratio?
Det beror på webbplatsen. En statisk eller marknadsföringswebbplats bör nå 98% eller högre, en blogg 95 till 98% och en butik som använder helsides cachelagring vanligtvis 85 till 95%, eftersom kundvagn, kassa och kontosidor alltid måste kringgå cacheminnet. En zon som endast tjänar statiska tillgångar bör vara på 99%; något lägre indikerar vanligtvis en felkonfiguration.
Hur kan jag förbättra min cache hit ratio?
Arbeta igenom fem orsaker i ordning: cache-kontroll rubriker på ditt ursprung som förhindrar cachning, frågesträngar som utm_source fragmentering en sida i många cache poster, Set-Cookie rubriker på statiska tillgångar, TTLs som är för kort, och en alltför bred Vary rubrik som Vary: User-Agent. Sortera dina CDN-loggar efter cachestatus och gruppera missar efter URL identifierar vilken som gäller snabbare än gissning.
Varför är min cache träffförhållande låg även om cache är aktiverat?
Nästan alltid för att något i svaret säger till CDN att inte lagra den. De vanliga bovarna är en Cache-Control header av no-store, privat eller max-age = 0 som skickas av ditt applikationsramverk, en Set-Cookie header på svar som ska delas, eller en Vary header som varierar på något med obegränsade värden som User-Agent. Kör curl -I mot ditt ursprung och inspektera de faktiska rubrikerna.
Saknar en cache missa besökaren?
- Javisst. En cache-träff serveras vanligtvis på under 20 millisekunder från närmaste kant, medan en miss kräver en fullständig rundtur till ditt ursprung plus vilken tid ditt ursprung behöver generera svaret - vanligtvis 200 Milisekunder eller mer, och betydligt värre för besökare på en annan kontinent. Varje fröken förbrukar också ursprung kapacitet och bandbredd du betalar för.
Ska jag sikta på en 100% cache träff ratio?
Nej. Cacheposter upphör att gälla, nytt innehåll måste hämtas minst en gång och rensar bort cacheminnet avsiktligt. Äkta personliga sidor som vagnar och kontopaneler bör missa varje gång - caching dem skulle vara en bugg och en potentiell dataläcka. Se upp för plötsliga droppar istället för att jaga ett absolut antal.
Så: 61%. Dra din missa lista, titta på de tjugo webbadresserna, och det finns en god chans att du tittar på antingen en oavsiktlig no-store eller en hög av ?utm_source= varianter. Båda är en konfigurationsändring, inte ett projekt.
Se hur NordicCDN gör detta för din webbplats:
Mads har arbetat inom IT - mestadels värd - sedan han var 16. Han tog tidigt del i ett SaaS-företag och hjälpte till att växa fram till Vismas förvärv, har byggt och drivit datacenternätverk och fungerat som CTO för ett danskt datacenter. Han startade NordicCDN för att göra snabb och säker infrastruktur enkel att använda.
