Cache hit ratio: hvad det er, og hvordan du får din over 95%
Det er det ene tal, der fortæller dig, om din 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 hit ratio siger 61%. Er det dårligt? Skal du være bekymret? Hvad gør du selv gøre ved det?
Dette kommer op en masse, og det ærlige svar er, at 61% er sandsynligvis dårlig, 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 din CDN modtager ender en af to måder. A hit betyder, at kanten allerede havde en frisk kopi og serveret den straks. A Frøken betyder det ikke, så det spurgte din oprindelse, ventede, videresendte svaret og holdt 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, 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 nogen: nogle dashboards rapporterer hit ratio ved anmodningstælling, andre ved bytes serveret. De kan være meget forskellige. Et websted, der serverer en enorm ucached video blandt en million små cachede 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 slags websted er spildt indsats.
| Områdetype | Realistisk mål | Hvorfor? |
|---|---|---|
| Statisk websted, docs, markedsføring | 98%+ | Næsten intet er personligt |
| Blog eller udgiver | 95–98% | Langvarige sider, tungt genbrug af aktiver |
| Shop med helsides caching | 85–95% | Kurv, checkout og konto altid omgå |
| Aktiv-only zone (billeder, JS, CSS) | 99% | Hvis det er lavere, er noget forkert konfigureret |
| Indlogget app | Varierer vildt | Dommer aktiver og sider separat |
Der er to ting, der følger af bordet. 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 den skyldige:
1. Din oprindelse fortæller CDN ikke at cache
Dette er den mest almindelige årsag til en afstand, og den mest tilfredsstillende at løse, fordi det normalt er en header. Cache-Control: no-store, private, eller 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 cache-indgange, en populær side er stille og roligt blevet flere hundrede poster, hver med et publikum på en. Hver del på sociale medier skaber en helt ny cache-nøgle, der aldrig vil blive anmodet om igen.
Fjern sporingsparametre fra cachenøglen. De betyder noget 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 header på et statisk aktiv gør CDN behandle dette svar som personlig og nægter at gemme det. Dit logo behøver ikke en cookie. Session 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 har ændret sig. app.a1b2c3.css kan sikkert cachelagres i et år, fordi en ny version får et nyt filnavn. HTML vil normalt have noget kortere, men "kortere" kan stadig betyde timer, hvis du kan rense på publicere.
5. En Vary header, du ikke mente at sende
Den subtile. Vary: User-Agent gør kanten gemme en separat kopi pr bruger-agent streng, og der er effektivt ubegrænset bruger-agent strenge. Dit hit ratio kollapser og intet i din config ser forkert. Vary: Accept-Encoding Det er fint og forventeligt; næsten alt andet fortjener et andet blik.
Hvis du kun gør én ting: sorter dine CDN-logfiler efter cachestatus, filtrer til fejl og grupper efter URL-adresse. De øverste tyve misses 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-poster udløber lovligt. Nyt indhold skal hentes én gang. Udrensninger tømme cachen med vilje. Og en virkelig personlig side en indkøbskurv, en konto dashboard bør savner hver gang, fordi caching det ville være en fejl og potentielt en datalækage.
Antallet at se 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. Pludselig bevægelse er et signal. 91% af en butik er tirsdag.
Ofte stillede spørgsmål
Hvad er en god cache hit ratio?
Det afhænger af stedet. En statisk eller marketing site skal 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%; noget 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-logs efter cachestatus og gruppering af fejl efter URL identificerer, hvilken der gælder hurtigere end at gætte.
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 User-Agent. Kør curl -I mod din oprindelse og inspicere de faktiske overskrifter.
Sætter en cache miss 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 rundtur 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 miss bruger også startkapacitet og båndbredde, du betaler for.
Skal jeg sigte efter en 100% cache hit ratio?
Nej. Cache-indgange 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 dråber i stedet for at jage et absolut tal.
Så: 61%. Træk din miss liste, se på de øverste tyve webadresser, og der er en god chance for, at du kigger på enten en utilsigtet no-store eller en bunke af ?utm_source= Begge er en konfigurationsændring, ikke et projekt.
Se, hvordan NordicCDN gør dette for dit websted:
Mads har arbejdet i IT - for det meste hosting - 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, sikker infrastruktur enkel at bruge.
