Så här rensar du din CDN-cache (och när du faktiskt borde)
Rensning är den stora röda knappen i CDN:er: den rensar cachen så att ändringar visas nu. Användbar, ibland nödvändig och lätt att överanvända – ofta som en ersättning för att lösa det faktiska problemet.
Varje CDN har en utrensningsknapp, och varje lag utvecklar så småningom en något ohälsosam relation med den. Det börjar som ett legitimt verktyg för att driva en korrigering live. Det blir, över ett år eller två, något folk klickar reflexivt när något ser fel, eftersom det är den kontroll som alla förstår.
Vilket är synd, eftersom en webbplats som behöver frekvent rensning vanligtvis är en webbplats med ett fixerbart konfigurationsproblem, och rensningen maskerar det.
Vad en utrensning faktiskt gör
Rensning tar bort ett cachelagrat objekt så att nästa begäran om det blir en cachefel. Kanten hämtar sedan en ny kopia från ditt ursprung, serverar den och lagrar den till nästa gång.
Lägg märke till konsekvensen: varje rensat objekt är en garanterad ursprungsbegäran inom en snar framtid. Rensa en URL och det är en begäran. Rensa allt på en upptagen webbplats och du har just schemalagt ett mycket stort antal samtidiga ursprungsförfrågningar, oavsett ögonblick din trafik nästa anländer.
De fyra typerna av utrensning
| Typ | Vad det rensar | Ursprungseffekt | Använd när |
|---|---|---|---|
| En enda webbadress | Ett exakt objekt | Försumbar | Du ändrade en sida |
| Prefix / jokertecken | Allt under en väg | Proportionell | Ett helt avsnitt har ändrats |
| Cache- tagg | Varje föremål som bär en tagg | Proportionell och exakt | En enhet visas på många sidor |
| Allt | Hela cachen | Allvarlig | Äkta nödsituationer |
Cachetaggar är de som är värda att sätta upp
Problemet med URL-baserad utrensning är att innehållet inte mappas snyggt till webbadresser. Ändra en produkts pris och den produkten visas på sin egen sida, tre kategorisidor, startsidans karusell, två samlingssidor och ett sökresultat. Att rensa "produktsidan" lämnar fem inaktuella priser.
Cachetaggar löser detta. Ditt ursprung fäster taggar på varje svar – en produktsida kan innehålla product-8842, category-boots, brand-acme och CDN indexerar objekt efter tagg. När produkten ändras rensar du taggen product-8842 och varje sida som innehåller den blir ogiltigförklarad på en gång, var den än befinner sig.
Detta tar en eftermiddag att koppla upp och eliminerar de flesta av orsakerna till att folk når för att rensa allt. Om du driver en butik eller en utgivare med något verkligt innehållsdiagram är det den timme som har högst värde i den här artikeln.
Varför purge-all gör mer ont än det ser ut
Tömning av hela cachen innebär att varje efterföljande begäran är en miss tills cachen fylls på. På en lugn plats som är bra. På en upptagen dag händer tre saker på en gång.
Ditt ursprung får en plötslig multipel av sin vanliga trafik – exakt den belastning som CDN finns för att förhindra, levererad utan förvarning. Dina svarstider klättrar för alla, eftersom varje besökare nu väntar på en fullständig startresa. Och om många besökare begär samma oupptäckta objekt samtidigt, får du en cachestämpels eller hundratals identiska samtidiga förfrågningar för en sida, eftersom det första svaret inte har kommit för att fylla i Cache än.
Bra CDN:er mildrar den senaste genom att kollapsa samtidiga fel för samma objekt till en enda ursprungsbegäran. Det är värt att bekräfta att din gör det, eftersom det är skillnaden mellan att en utrensning är en blip och att en utrensning är en incident.
Om du måste rensa allt på en webbplats med hög trafik, gör det när du är tystast och värm cachen efteråt genom att krypa dina bästa webbadresser. Tio minuter av att krypa din egen webbplatskarta är mycket billigare än en timme av riktiga besökare som var och en betalar för en miss.
Mjuk utrensning
En förfining värd att mjuk utrensning tar bort objektet. En mjuk rensning markerar den inaktuella istället, lämnar den i cacheminnet - så om ursprunget är långsamt eller otillgängligt kan kanten fortfarande tjäna den inaktuella kopian medan den förnyas, snarare än att ha ingenting alls.
För innehåll där en något föråldrad version är bättre än en felsida, vilket är det mesta innehållet, är mjukrensning den säkrare standarden. Reservera hårda utrensningar för saker som verkligen aldrig får serveras igen - en sida med felaktig prissättning eller innehåll som dras tillbaka av juridiska skäl.
När du ska rensa
Innehållet har ändrats och ändringen är tidskänslig
Ett korrigerat pris, en publicerad artikel, en återtagen produkt. Rensa den här webbadressen eller taggen.
Något fel har cachats
En felsida, ett halvt återgivet svar, en sida cachad med fel valuta. Rensa det och fixa sedan anledningen till att det var cacheable.
Du distribuerade något som ändrar delad utdata
En malländring som påverkar varje sida. Detta är en av de få legitima breda utrensningarna - och cachetaggar låter dig täcka det.
När du inte bör
- Efter att ha använt fingeravtryck. Nytt innehåll innebär ett nytt filnamn, vilket är en ny cachenyckel. Det finns inget att rensa ut.
- Som ett felsökningssteg. Att rensa för att se om det hjälper till att förstöra bevisen och berättar väldigt lite.
- Jag har ett schema. Ett cron-jobb som rensar cachen varje natt är en TTL som uttrycks på det dyraste sättet. Ställ in TTL istället.
- För att du inte är säker. Kontrollera rutan
AgeochCache-ControlRubrikerna först. De flesta rapporter om att "cachen är gammal" visar sig vara en webbläsarens cache, vilket rengör CDN inte gör någonting åt.
Den sistnämnda förtjänar att betonas, eftersom den står för en hel del onödiga utrensningar. Om en besökares webbläsare har cachat en sida i en timme hjälper det inte att rensa CDN-numret – de frågar inte CDN-numret. Det är just därför s-maxage finns: håll webbläsarens livslängd kort och lång, så rengöringen är faktiskt effektiv när du gör det.
Vanliga frågor
Vad gör det att rensa en CDN-cache?
Rensning tar bort cachade objekt från CDN så att nästa begäran om dem måste hämtas färskt från ditt ursprung. Det är så du tvingar en uppdatering att visas omedelbart istället för att vänta på att den cachade kopians TTL ska upphöra att gälla. Varje rensat objekt resulterar i minst en efterföljande ursprungsbegäran.
Hur ofta ska jag rensa min CDN-cache?
Sällan, och bara som svar på en specifik förändring. Frekvent rensning indikerar vanligtvis TTL som är inställda fel eller tillgångar som saknar innehåll hash i sina filnamn - rensningen kompenserar för ett konfigurationsproblem snarare än att lösa ett. Schemalagda utrensningar är särskilt slösaktiga, eftersom en TTL uppnår samma sak utan att tömma cachen.
Är det dåligt att rensa hela cachen?
På en upptagen plats, ja. Varje efterföljande begäran blir en cache miss tills cache påfyllningar, som skickar ditt ursprung en plötslig multipel av sin normala belastning och kan utlösa en cache stampede där många identiska samtidiga förfrågningar anländer för samma orörda föremål. Föredrar att rensa efter URL eller cachetag, och om en fullständig rengöring är oundviklig, gör det under tysta timmar och värm cachen efteråt.
Vad är cachetaggar och varför använda dem?
Cachetaggar är etiketter som ditt ursprung bifogar till svar så att CDN kan indexera cachade objekt efter enhet snarare än bara efter webbadress. En produktsida kan vara märkt med produkt-ID, kategori och varumärke, och varje sida som innehåller produkten bär också taggen. Att ändra produkten kräver att du rensar en tagg istället för att leta efter varje webbadress där den visas.
Måste jag rensa efter att ha distribuerat ny CSS eller JavaScript?
Inte om din build producerar fingeravtryck filnamn som app.a1b2c3.css. En ändring av filen ger ett nytt filnamn och därför en ny cachenyckel, så den gamla posten är helt enkelt aldrig begärd igen och löper ut på egen hand. Utrensning är endast nödvändig för tillgångar som används under ett stabilt filnamn.
Varför ser jag fortfarande gammalt innehåll efter att jag rensat CDN?
Oftast eftersom den gamla kopian finns i din webbläsare, inte CDN, och rensa en CDN kan inte nå den. Kontrollera med en hård omladdning eller ett privat fönster. Det är därför HTML bör bära en kort max-ålder tillsammans med en lång s-maxage - webbläsare håller den kort medan kanten håller den länge - eftersom en CDN kan rensas och en webbläsare inte kan.
Rensa efter webbadress eller, bättre, efter cachetagg; behåll utrensningen för nödsituationer och värm cachen efteråt. Föredrar mjuka rengöringar så att en gammal kopia förblir tillgänglig om ursprunget kämpar. Och om du rensar ofta, behandla det som en signal för att fixa dina TTL och lägga till innehållshash till filnamn - en cache du måste babysit är en cache som är felkonfigurerad.
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.
