Cacheträffförhållande: vad det är och hur du får din över 95%
Det är den enda siffran som talar om för dig om din CDN faktiskt gör sitt jobb. Vad det betyder, de fem sakerna som vanligtvis förstör det, och hur man räknar ut vilken som förstör din.
Du sätter webbplatsen bakom ett CDN, instrumentbrädan har varit uppe i en vecka och cache träffförhållandet säger 61%. Är det dåligt? Borde du vara orolig? Vad gör du ens åt det?
Detta kommer upp mycket, och det ärliga svaret är att 61% förmodligen är dåligt men inte nödvändigtvis - det beror helt på vad din webbplats är. Så låt oss börja med vad numret egentligen 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. A träff Det betyder att kanten redan hade en ny kopia och serverade den omedelbart. A fröken Det 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äff-förhållandet ä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 som du betalar för på båda benen och lite mindre utrymme när trafiken ökar. Multiplicera ett lågt förhållande mellan 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 annan: vissa instrumentpaneler rapporterar träffkvot efter antal förfrågningar, andra efter antal byte som visas. De kan skilja sig vilt åt. En webbplats som serverar en enorm uncached video bland en miljon små cachade tillgångar har ett utmärkt förhållande mellan begäran och ett fruktansvärt byteförhållande. Om din bandbreddsräkning och ditt träffförhållande verkar vara oense, är det vanligtvis därfö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 den på fel typ av webbplats är bortkastad ansträngning.
| Webbplatstyp | Realistiskt mål | Varför? |
|---|---|---|
| Statisk webbplats, dokument, 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 cachelagring | 85–95% | Varukorg, kassa och konto bypass alltid |
| Zon endast för tillgångar (bilder, JS, CSS) | 99% | Om den är lägre är något felkonfigurerat |
| Inloggad app | Varierar vilt | Döm tillgångar och sidor separat |
Två saker följer från det 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%, är det 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 skyldig:
1. Ditt ursprung säger till CDN att inte cachelagra
Detta är den vanligaste orsaken på avstånd, och den mest tillfredsställande att fixa eftersom det vanligtvis är en rubrik. En herrelös Cache-Control: no-store, privateeller max-age=0 säger att kanten ska hoppa över cachningen helt och hållet. 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 spårningsparametrar från cache-nyckeln. De är viktiga för din analys, som läser dem i webbläsaren, och inte alls vilka bytes du återvänder till.
3. Cookies på saker som inte behöver dem
A Set-Cookie Huvudet på en statisk tillgång gör att CDN behandlar svaret som personligt och vägrar att lagra det. Din logotyp behöver ingen cookie. Sessionsmellanprogram som körs på alla rutter, inklusive tillgångsrutter, är den vanliga källan.
4. TTL är för korta
Om innehållet går ut efter 60 sekunder, spenderar kanten sitt liv på att hämta saker som inte förändrats. Fingeravtryckta tillgångar app.a1b2c3.css kan säkert cachas i ett år, eftersom en ny version får ett nytt filnamn. HTML vill oftast ha något kortare, men "kortare" kan ändå betyda timmar om man kan rensa på publicering.
5. Ett Vary-huvud som du inte menade att skicka
Den subtila. Vary: User-Agent gör att kanten lagrar en separat kopia per användaragentsträng, och det finns effektivt obegränsade användaragentsträngar. Ditt träffförhållande kollapsar och inget i din konfiguration ser fel ut. Vary: Accept-Encoding Den är fin och förväntad; nästan allt annat förtjänar en andra titt.
Om du bara gör en sak: sortera dina CDN-loggar efter cachestatus, filtrera efter fel och gruppera efter webbadress. 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 procent ä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ömma cachen med flit. Och en verkligt personlig sida - en vagn, ett konto instrumentbräda - bör missa varje gång, eftersom caching det skulle vara en bugg och potentiellt en dataläcka.
Antalet 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 förä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. En stadig 91% på en butik är bara tisdag.
Vanliga frågor
Vad är en bra cache hit ratio?
Det beror på platsen. 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 betjänar statiska tillgångar bör vara 99 %; allt lägre indikerar vanligtvis en felkonfiguration.
Hur förbättrar jag min cache hit ratio?
Arbeta igenom fem orsaker i ordning: cache-kontroll rubriker på ditt ursprung som förhindrar cachelagring, 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. Genom att sortera dina CDN-loggar efter cachestatus och gruppera fel efter URL identifieras vilken som tillämpas snabbare än gissning.
Varför är mitt cacheslagsförhållande lågt trots att cachelagring är aktiverat?
Nästan alltid för att något i svaret säger åt CDN att inte lagra det. 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-miss besökaren?
Jaha. En cacheträ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å ursprungskapacitet och bandbredd som du betalar för.
Ska jag sikta på en 100 % cacheträff?
Nej. Cacheposter löper ut på ett lagligt sätt, nytt innehåll måste hämtas minst en gång och rensas bort från cachen 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 fall snarare än att jaga ett absolut antal.
Så: 61%. Dra din misslista, titta på de tjugo bästa webbadresserna, och det finns en bra 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 som värd – sedan han var 16. Han tog tidigt del i ett SaaS-företag och hjälpte till att växa fram till förvärvet av Visma, 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.
