Hva er caching? En forklaring på klarspråk for appbyggere

Caching betyr å holde en ferdig kopi av noe som var tregt eller dyrt å hente, slik at neste forespørsel om det kan besvares raskt fra den kopien. Den lagrede kopien kalles en cache. Nettleseren din cacher bilder slik at en side laster raskere ved ditt andre besøk; en server cacher resultatet av en treg databasespørring slik at den ikke må kjøres for hver besøkende.

Caching gjør apper raskere og billigere å drifte. Dens ene store avveining er at en kopi kan bli utdatert.

Hvorfor caching betyr noe når du bygger med KI

Du vil møte caching i KI-bygde apper på tre måter:

• «Jeg oppdaterte appen, men jeg ser fortsatt den gamle versjonen.» Dette er det vanligste caching-øyeblikket, og det er vanligvis ufarlig – nettleseren din eller et CDN viser en lagret kopi.
• Hastighet. Hvis en side er treg fordi den regner ut de samme tallene for hver besøkende, kan caching av resultatet få den til å føles øyeblikkelig.
• Kostnad. Mange KI-appbyggere og hosting-tjenester tar betalt for regnekraft, databasetid og eksterne API-kall. Hvis tusen besøkende utløser den samme dyre forespørselen, lar caching deg betale for den én gang.

Å kjenne det grunnleggende lar deg be om caching der den hjelper, og oppdage den når den er grunnen til at noe ser feil ut.

En hverdagslig analogi

Tenk deg kjøkkenet på et travelt kafeteria.

Hver morgen kunne kokken brygge hver kaffe av nymalte bønner når den bestilles. Det er tregt. I stedet holder han en kanne filterkaffe klar på platen. De fleste kunder får en kopp på sekunder – det er en cache-treff. Når kannen er tom, brygger noen en ny – en cache-bom.

Men kaffe som står for lenge blir gammel, så kafeteriaet har en regel: kast enhver kanne som er eldre enn 30 minutter. Den regelen er cachens utløpstid. Ingen ville holdt den samme kannen hele dagen, og ingen ville forhåndsbrygget en spesialbestilling med havremelk og tre sukker – noen ting bør ikke caches i det hele tatt.

Hvor cacher ligger

En enkelt sidelasting kan gå gjennom flere cacher, fra nærmest brukeren til lengst unna:

Et CDN (content delivery network) er i praksis et verdensomspennende nettverk av cacher for nettstedets filer.

Hvordan en cache bestemmer hva den beholder

Hver cache må svare på de samme spørsmålene:

• Hva kan caches? Offentlige, delte data (et produktbilde, et blogginnlegg) – ja. Private data (en brukers kontoside, meldingene deres) – aldri i en delt cache.
• For hvor lenge? Dette er TTL (time to live). En logo kan caches i et år; et lagerantall i 30 sekunder.
• Hvordan oppdateres den? Enten utløper kopien og hentes på nytt, eller appen fjerner den bevisst når dataene endres – kalt invalidering.

For nettsider forteller serveren nettlesere og CDN-er hvordan hver fil skal caches, ved hjelp av Cache-Control-headeren. For eksempel betyr Cache-Control: max-age=3600 «du kan gjenbruke denne kopien i en time».

Moderne byggeverktøy håndterer den vanskeligste delen for statiske filer med cache-busting: hver gang en fil endres, får den et nytt navn med et fingeravtrykk, som app.3f9a2c.js. Nettlesere kan cache det gamle navnet lenge, fordi den nye versjonen rett og slett har et annet navn.

Et praktisk eksempel: en produktkatalog

Du har en liten nettbutikk. Forsiden viser 50 produkter med priser og lagerstatus fra databasen, pluss en «trending»-liste som krever en treg beregning på tvers av alle bestillinger.

1. Bilder og skript caches av nettleseren og CDN-et i lang tid. Hvert nytt bygg gir endrede filer nye navn, så oppdateringer vises fortsatt.
2. Trending-listen beregnes én gang hvert 10. minutt og lagres i en applikasjonscache. Hver besøkende i de 10 minuttene får det lagrede resultatet øyeblikkelig.
3. Priser caches i kort tid, og cachen tømmes hver gang du redigerer et produkt, slik at kunder aldri ser en gammel pris lenge.
4. Lager ved kassen caches aldri. Når noen klikker «Kjøp», sjekker appen den virkelige databasen, slik at den ikke kan selge en vare som nettopp ble utsolgt.
5. Handlekurv- og kontosider lagres aldri i delte cacher, fordi de er personlige.

Resultatet: forsiden er rask, databasen gjør mye mindre arbeid, og ingenting som betyr noe for penger eller personvern er noen gang utdatert.

Nøkkelbegreper

Vanlige misforståelser

• «Caching er alltid bra.» Å cache feil ting skaper ekte feil: gamle priser, manglende nye innlegg, eller – i verste fall – en privat side for én bruker vist til en annen. Cache bevisst.
• «Hvis jeg ser den gamle versjonen, feilet oppdateringen.» Vanligvis gjorde den ikke det. Prøv en hard oppdatering (Ctrl+Shift+R, eller Cmd+Shift+R på Mac) eller et privat vindu før du antar at noe er ødelagt.
• «Caching fikser en treg app.» Det skjuler tregheten for gjentatte forespørsler. Den første forespørselen er fortsatt treg, og hvis det underliggende problemet er en manglende databaseindeks, må du fikse den også.
• «Jeg bør cache alt så lenge som mulig.» Lange cachetider passer for filer som får nye navn når de endres. For HTML-sider og data er kortere tider tryggere.
• «Å tømme cachen min fikser det for alle.» Det tømmer bare din nettleser. Besøkende og CDN-cacher har fortsatt sine egne kopier.

Hva du bør spørre KI-appbyggeren din om

• «Hvilke deler av denne appen er trege, og hvilke kan caches trygt?»
• «Cache [trending-listen / API-resultatet] i [N] minutter, og tøm den når de underliggende dataene endres.»
• «Sørg for at ingen side med personlige data eller kontodata kan caches av et CDN eller en delt cache.»
• «Sett lange cachetider for filer med fingeravtrykk og korte for HTML.»
• «Cache svar fra [eksternt API] slik at vi ikke kaller det ved hver sidelasting – og fortell meg hvor utdaterte dataene kan bli.»
• «Jeg ser en gammel versjon etter publisering. Er det nettleserens cache, eller er noe ikke distribuert?»

Caching i Mythex

Etter at du har publisert en oppdatering av en Mythex-app, sier dokumentasjonen at CDN-cacher kan henge litt etter, og at en hard oppdatering av den offentlige URL-en viser den nye versjonen – se Slik publiserer du. Siden Hostingbegrensninger anbefaler også caching av statiske ressurser, fordi hosting, databasetid og båndbredde betales fra kredittsaldoen din. Alt utover det – caching av spørringsresultater eller API-svar – er noe du ber agenten bygge inn i appen din.

Relatert lesing: hva et CDN er, hvordan du gjør nettsiden din raskere og hva hastighetsbegrensning er.

Spørsmål