Statisk caching
Caching er i mange tilfeller det viktigste virkemiddelet man kan ta i bruk for å øke ytelsen på nettsteder. Altfor mange av dagens nettsteder (inkludert dette...) gjør langt flere "on-the-fly" sidevisninger enn det som er nødvendig. Statisk caching kan for mange applikasjoner gi utrolig boost i ytelse.
Om genererte sidevisninger
Veldig mange nettsteder idag har en database i bakkant. Dette er spesielt sant med spredningen av blogge-programvare som Wordpress, og andre bloggetjenester som Blogger o.l. De fleste av disse genererer alle sider hver gang noen vil se dem. Eksempelvis skjer ofte følgende når du besøker forsiden på en blogg:
- Databasen leter opp nye innlegg (for eksempel de 10 siste)
- Server-side kode bearbeiderer informasjonen fra databasen
- Resultatet spyttes ut til klienten som HTML
For det meste er dette unødvendig arbeid. Den eneste gangen det egentlig er nødvendig å hente noe som helst fra databasen er når du har lagt noe nytt inn i den. Når du legger noe nytt inn i databasen kan forsiden genereres på nytt, og hentes opp til alle som vil se. På denne måten vil siden være like rask som en statisk side, fordi den er det. Hvorfor vente på masse prossessering oftere enn nødvendig?
Hvordan funker statisk caching?
Statisk caching kan gi ytelsesboost på linje med statiske filer fordi vi kan forbigå hele applikasjonen når cachen er generert. Det eneste applikasjonen trenger å gjøre i dette tilfellet er å generere sider. Å generere dem er minimum, å slette dem er bonus, men ikke nødvendig. Så fort applikasjonen genererer cache-filer kan vi konfigurere Apache til å servere de direkte.
RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^POST$
RewriteCond /var/www/minsite/var/cache/static$1/index.html -f
RewriteRule ^(.*)$ /var/www/minsite/var/cache/static$1/index.html [L]
RewriteRule .* /index.app
Konfigurasjonen over bruker mod_rewrite til å sjekke om URL-en har en statisk versjon på filsystemet, og viser i så fall den. Hvis ikke sender den trafikken videre til index.app som her er applikasjonen vår.
La oss si at applikasjonen tar imot trafikk på URL-en /blogg. Første gang finnes det ikke noe cache. Applikasjonen passer derfor på som det siste den gjør å lagre resultatet (hele siden) i filen /var/www/minsite/var/cache/static/blogg/index.html. Neste gang vil testen i rewrite-koden over slå til, og den samme html-filen serveres rett fra filsystemet, uten at applikasjonen så mye som sneies.
Når passer det med statisk caching?
Ut ifra beskrivelsen over er det fristende å tenke at statisk caching er løsningen på alle dine ytelsesproblemer. Desverre er det ikke så vel. Det er to ting som kan komme i veien for statisk caching:
- En URL returnerer forskjellig innhold ettersom hvem det er som ser på den (logget inn/ikke logget inn, sesjons-data osv)
- En URL returnerer forskjellig innhold ettersom når på døgnet/i uka/i måneden det er (altså, tidsavhengig innhold)
Dersom ingen av disse er aktuelle for deg er det bare å kjøre på med statisk caching. Når du så setter igang er det viktig å bestemme deg for hvordan cache skal fornyes. Du har grovt sett to valg:
- En "sweeper" - en prosess på serveren som fjerner filer jevnlig
- Applikasjonen sletter cache-filer når de har utgått
For bloggeksempelet over vil du typisk ønske å slette cachete filer når det publiseres nye innlegg eller kommentarer (eller disse endres) på bloggen. Trikset er å huske at det ikke er nok å slette cache for den aktuelle siden som endres/opprettes, men også alle sider som lister opp denne eller på annen måte viser innhold fra den.
Her kan det igjen dukke opp problemer - hvis du benytter deg av utbredt krysslinking av innhold kan jobben med å rydde cache-filer bli så stor at gevinsten går opp i vinninga. Et eksempel:
En blogg lister alle artikler med antall kommentarer på forsiden, kategorisider, og arkivsider. Opprettes det en kommentar under denne artikkelen må cachen oppdateres for:
- Artikkel-siden
- Forsiden, hvis artikkelen er rimelig ny
- Kategorisider for alle artikkelens kategorier
- Arkivsider, muligens år og måned
Dette er en overkommelig oppgave. La oss si at du også lister opp artikler fra relaterte kategorier til andre artikler, altså slik det gjøres her. Endrer du nå en artikkel må cache ryddes for artikkelen, listingene, forsiden og samtlige andre artikler i samme kategorier. Nå er vi muligens på et sted hvor det ikke lengre er formålstjenestelig å drive med dette.
Hvis du vurderer det slik at statisk caching funker for deg vil jeg på det varmeste anbefale deg å implementere det. For mange verktøy er dette bygget inn, Rails og eZ Publish har begge statisk caching bygget rett inn. Det samme har andre utviklingsrammeverk. Har ikke ditt rammeverk denne muligheten bygget inn, forvil ikke, det er ganske lett å implementere.
Kommentarer er stengt