Cache hit ratio: hvad det er, og hvordan du får din over 95%
Det er det eneste tal, der fortæller dig, om dit CDN rent faktisk gør sit arbejde. Hvad det betyder, de fem ting, der normalt ødelægger det, og hvordan man finder ud af, hvilken der ødelægger din.
Du sætter webstedet bag en CDN, instrumentbrættet har været oppe i en uge, og cache-hitforholdet siger 61%. Er det slemt? Skal du være bekymret? Hvad gør du ved det?
Dette kommer op meget, og det ærlige svar er, at 61% sandsynligvis er dårligt, men ikke nødvendigvis - det afhænger helt af, hvad dit websted er. Så lad os starte med, hvad tallet faktisk betyder, og derefter arbejde gennem diagnosticere din, fordi fix er næsten altid en af fem specifikke ting.
Hvad betyder nummeret
Hver anmodning, som dit CDN modtager, ender på en af to måder. A hit betyder, at kanten allerede havde en frisk kopi og serveret den med det samme. A misse Det betyder, at det ikke gjorde det, så det spurgte din oprindelse, ventede, videresendte svaret og beholdt en kopi til næste gang. Cache hit ratio er hits divideret med samlede anmodninger.
En miss er ikke bare langsommere for den ene besøgende. Det er en anmodning, som din oprindelse skal håndtere, båndbredde, du betaler for på begge ben, og lidt mindre plads til, når trafikken stiger. Multiplicer et lavt forhold på tværs af millioner af anmodninger, og du kører et globalt netværk som et dyrt gennemløb.
Anmodninger eller bytes?
Værd at vide, før du sammenligner tal med andre: Nogle dashboards rapporterer antal hits efter antal anmodninger, andre efter antal bytes, der vises. De kan være vidt forskellige. Et websted, der serverer en enorm uovertruffen video blandt en million små cachelagrede aktiver, har et fantastisk forespørgselsforhold og et forfærdeligt byteforhold. Hvis din båndbredderegning og dit hitforhold synes at være uenige, er det normalt derfor - tjek hvilken du kigger på.
Hvad er egentlig et godt forhold?
"Over 95%" i titlen er et rimeligt mål for de fleste websteder, men det er ikke universelt, og jagter det på den forkerte form for websted er spildt indsats.
| Webstedtype | Et realistisk mål | Hvorfor? |
|---|---|---|
| Statisk websted, dokumenter, markedsføring | 98%+ | Næsten intet er personligt |
| Blog eller udgiver | 95–98% | Langvarige sider, omfattende genbrug af aktiver |
| Shop med helsides cachelagring | 85–95% | Kurv, checkout og konto altid omgå |
| Zone kun for aktiver (billeder, JS, CSS) | 99% | Hvis den er lavere, er der noget, der er forkert konfigureret |
| Indlogget app | Varierer vildt | Dommerens aktiver og sider separat |
Der er to ting, der følger af det bord. For det første, hvis du kører en butik, skal du ikke gå i panik på 88% - en del af din trafik er checkout og kontosider, der aldrig må cachelagres, og ekskludere dem korrekt er systemet fungerer. For det andet, hvis du har en separat zone for statiske aktiver, og det er under 99%, det er en ægte fejlkonfiguration og værd ti minutter af din tid.
Diagnosticering af et lavt forhold
I grov rækkefølge af, hvor ofte hver viser sig at være skyldige:
1. Din oprindelse fortæller CDN ikke at cachelagre
Dette er den mest almindelige årsag med en afstand, og den mest tilfredsstillende at rette, fordi det normalt er en overskrift. En vildfaren mand Cache-Control: no-store, privateeller max-age=0 fortæller kanten at springe caching helt over. Rammer tilføjer disse som standard oftere, end du ville forvente, især for HTML.
Tjek, hvad din oprindelse faktisk sender, ikke hvad du tror, den sender:
curl -sI https://origin.example.com/some-page | grep -iE 'cache-control|set-cookie|vary'2. Forespørgselsstrenge fragmenterer cachen
Hvis /product, /product?utm_source=newsletter og /product?fbclid=abc123 er tre separate cacheposter, en populær side er stille blevet flere hundrede poster, hver med et publikum på en. Hver eneste del på sociale medier skaber en helt ny cachenøgle, som aldrig vil blive efterspurgt igen.
Fjern parametre for sporing fra cachenøglen. De er vigtige for dine analyser, som læser dem i browseren, og slet ikke hvilke bytes du vender tilbage til.
3. Cookies på ting, der ikke har brug for dem
A Set-Cookie Hvis CDN'en har et overskriftsfelt på et statisk aktiv, behandles dette svar som personaliseret og nægter at gemme det. Dit logo behøver ikke en cookie. Sessions-middleware, der kører på alle ruter, herunder aktivruter, er den sædvanlige kilde.
4. TTL'er er for korte
Hvis indholdet udløber efter 60 sekunder, bruger kanten sit liv på at hente ting, der ikke ændrede sig. Fingeraftryksaktiver app.a1b2c3.css kan cachelagres sikkert i et år, fordi en ny version får et nyt filnavn. HTML ønsker normalt noget kortere, men "kortere" kan stadig betyde timer, hvis du kan rense på udgivelse.
5. En Vary-overskrift, du ikke mente at sende
Den subtile. Vary: User-Agent gør kanten til en separat kopi pr. brugeragentstreng, og der er effektivt ubegrænset brugeragentstrenge. Dit hitforhold kollapser, og intet i din konfiguration ser forkert ud. Vary: Accept-Encoding Det er fint og forventet; næsten alt andet fortjener et andet kig.
Hvis du kun gør én ting: Sorter dine CDN-logfiler efter cachestatus, filtrer til fejl og grupper efter URL-adresse. De øverste tyve fejl vil fortælle dig, hvilken af de fem ovenfor du har, normalt inden for et minut. At gætte tager længere tid end at kigge.
Hvorfor 100 % er det forkerte mål
Du kan ikke nå 100%, og et websted, der gjorde, ville være mistænkeligt. Cache- indgange udløber lovligt. Nyt indhold skal hentes én gang. Purges tømme cachen med vilje. Og en virkelig personlig side - en indkøbskurv, en konto dashboard - bør gå glip af hver gang, fordi caching det ville være en fejl og potentielt en datalækage.
Tallet, du skal holde øje med, er ikke den absolutte værdi så meget som dens form over tid. Et forhold, der var 96% og er nu 78% betyder noget ændret: en implementering ændrede dine overskrifter, en kampagne tilføjede nye forespørgselsparametre eller nogen sendte en cookie på dine aktivruter. Pludselige bevægelser er et signal. 91% af en butik er kun tirsdag.
Ofte stillede spørgsmål
Hvad er en god cache hit ratio?
Det afhænger af stedet. En statisk eller marketing site bør nå 98% eller højere, en blog 95 til 98%, og en butik ved hjælp af fuld-side caching typisk 85 til 95%, fordi indkøbskurv, checkout og konto sider skal altid omgå cachen. En zone, der kun betjener statiske aktiver, bør være på 99 %; alt lavere indikerer normalt en fejlkonfiguration.
Hvordan forbedrer jeg min cache hit ratio?
Arbejd gennem fem årsager i rækkefølge: cache-control headers på din oprindelse, der forhindrer caching, forespørgselsstrenge som utm_source fragmentering af en side i mange cache-poster, Set-Cookie headers på statiske aktiver, TTL'er, der er for korte, og en over-bred Vary header som Vary: User-Agent. Sortering af dine CDN-logfiler efter cachestatus og gruppering af fejl efter URL-adresse identificerer, hvilken der anvendes hurtigere end gættet.
Hvorfor er min cache hit ratio lav, selvom caching er aktiveret?
Næsten altid fordi noget i svaret fortæller CDN ikke at gemme det. De sædvanlige syndere er en Cache-Control header af no-store, privat eller max-age = 0 sendt af din ansøgning ramme, en Set-Cookie header på svar, der skal deles, eller en Vary header, der varierer på noget med Ubegrænsede værdier som f.eks. brugeragent. Kør curl -I mod din oprindelse og inspicer de faktiske overskrifter.
Sætter en cache-fejl besøgende langsommere?
Ja, ja. Et cache-hit serveres typisk på under 20 millisekunder fra nærmeste kant, mens en miss kræver en fuld tur til din oprindelse plus den tid, din oprindelse skal generere svaret - almindeligvis 200 millisekunder eller mere, og betydeligt værre for besøgende på et andet kontinent. Hver eneste miss bruger også oprindelseskapacitet og båndbredde, som du betaler for.
Skal jeg stræbe efter et 100 % cache-hitforhold?
Nej. Cacheposter udløber lovligt, nyt indhold skal hentes mindst én gang, og udrensninger tømmer cachen bevidst. gte personlige sider som vogne og konto dashboards bør gå glip af hver gang - caching dem ville være en fejl og en potentiel datalækage. Hold øje med pludselige fald i stedet for at jagte et absolut tal.
Så: 61%. Træk din liste over savnede, se på de øverste tyve webadresser, og der er en god chance for, at du kigger på enten en utilsigtet eller ikke-tilsigtet liste. no-store eller en bunke af ?utm_source= varianter. Begge dele er en config-ændring, ikke et projekt.
Se, hvordan NordicCDN gør dette for dit websted:
Mads har arbejdet med IT – mest som vært – siden han var 16. Han tog tidligt ejerskab i en SaaS-virksomhed og var med til at udvide den til Visma, har opbygget og drevet datacenternetværk og fungeret som CTO for et dansk datacenter. Han startede NordicCDN for at gøre hurtig og sikker infrastruktur enkel at bruge.
