Server-side cache giver fart på webserveren

En simpel måde at optimere de dynamiske websider er at generere HTML-koden på forhånd. Der kan spares processorkraft og databasekald, og loadingtiderne nedsættes.

Hvad er cache

En forholdsvis nem måde at optimere ydelsen på dynamisk producerede websider er at generere koden på forhånd. Det kan lyde lidt paradoksalt, for forskellen mellem statiske og dynamiske websider er jo netop, at indholdet på de sidstnævnte ændrer sig over tid. Men for mange websites dækker de dynamiske sider over et publiceringssystem, hvor en stor del af indholdet kun ændres sjældent. Situationen bliver dog mere mudret af, at enkelte elementer, som for eksempel bannere, skal skifte for hver enkelt forespørgsel.

Hvis genereringen af en enkelt side kræver en større mængde processeringsarbejde og databasekald, kan cache - midlertidig lagring af webindhold - være en nem måde at få has på flaskehalsene.

Hvad er cache
Når talen drejer sig om websider, betyder cache en midlertidig lagring af kopieret webindhold, tættere på slutbrugeren. Det kan være lokalt i browseren, ved en proxy-server, eller direkte i den kode, som genererer websiderne.

Tre metoder

Fordelene og spørgsmål
Et dynamisk websted bygger ofte på en relationsdatabase, som indeholder de forskellige elementer, som siderne opbygges af. Hvis en forside kræver adskillige kald til den bagvedliggende database, eller hvis der indgår en stor mængde kode bag genereringen, så kan caching reducere loadingtider ganske drastisk og nedsætte belastningen på web- og databaseserverne.

De spørgsmål, man skal forholde sig til, når man implementerer server-side cache i sine webscripts og webprogrammer, er hvad der skal caches, og hvor cachen skal gemmes.

Tre typer caching
Man kan groft opdele server-side caching i tre typer:

  • Data-caching
    Her gemmes de data, som oftest hentes fra den bagvedliggende datakilde. Det vil ofte være brugbart, hvis der er tale om en kompleks SQL-sætning, som trækker mange ressourcer.
  • Element-caching
    Element-caching tager et enkelt element og genererer den færdige HTML-kode.
  • Side-caching
    Side-caching fungerer ligesom element-caching, men renderer hele siden.

Hvor skal cachen gemmes
Der er grundlæggende tre steder at opbevare den genererede cache:

  • Application-variable
    I ASP og JSP har man mulighed for at definere applikations-variable. Det er variable, hvis rækkevidde (scope) går ud over alle forespørgsler. Der er altså kun én variabel for den pågældende applikation (website), så der skal ikke instantieres en ny version af variablen for hver enkel forespørgsel. Applikations-variable er velegnede til caching af ofte viste sider som for eksempel websitets forside. I PHP tilbyder funktionerne shm_put_var() og shm_get_var() samme muligheder, men fungerer i parentes bemærket kun under Unix (og Linux). Applikations-variable er hurtigere end de andre måder der er beskrevet her, men man kan selvfølgelig ikke gemme alle siderne på webstedet.
  • Database-felter
    Et andet sted at gemme det cachede indhold er i databasen. Hvis der ligger en stor mængde processering bag hver enkel side, kan indholdet gemmes i en tabel. Denne metode er velegnet til sider, der ikke vises så ofte.
  • Flade filer
    Den sidste mulighed er flade filer. Hvis siderne ikke indeholder egentligt dynamisk indhold som bannere eller andet, fås den bedste ydelse ved simpelthen at generere HTML-sider.

I den næste artikel om server-side cache ser vi på, hvorledes principperne implementeres, og kigger på konkrete kodeeksempler.

Forskellige slags cache

Der er flere slags måder at cache webindhold på, og de er principielt forskellige.

  • Klient-cache
    Stort set alle web-browsere benytter cache. Når en webside besøges, gemmer browseren en kopi af siden på computerens harddisk. Herfra kan websiden hentes igen, når der er bud efter den. Efter et vist interval vil browseren dog hente siden igen fra webstedet, således at man altid får den senest opdaterede version. Problemet her er, at de fleste større websteder har dynamisk indhold som for eksempel reklamebannere, og dermed skal siderne opfriskes hele tiden.

    Webserveren styrer, hvor lang tid der går, før at siden når "sidste salgsdato". Dette gøres ved at sætte en række header-felter i HTTP-svaret til browseren.

  • Proxy
    En proxy-server udfører samme funktion som den lokale cache, men er implementeret som en server, således at mange brugere kan benytte den samme cache. Jo tættere på brugeren proxyen er placeret, jo mere netværkstrafik spares der. En internetudbyder kan således opsætte en proxy-server for at spare på trafikken videre på netværket, men proxy-server kan også bruges internt i virksomheden eller organisationen, og det kan faktisk give væsentlige besparelser.

  • Omvendt proxy
    Omvendt proxy (reverse proxy) benyttes i den anden ende, det vil sige umiddelbart efter serveren, der egentlig leverer eller genererer indhold. Hvis en webtjeneste for eksempel fungerer som front-end for en database, kan en omvendt proxy gemme de sider, som brugerne oftest forespørger. Der kan også være en sikkerhedsmæssig fordel i at benytte omvendt proxy. Ligesom i de andre typer af proxy, må siderne opdateres, når indholdet ændrer sig.

    Princippet i omvendt proxy.

  • Server-side caching
    Server-side caching, emnet for denne artikel, går ud på, at cache direkte i de scripts eller den kode, som genererer webstedet. Den store fordel her, er at man kan tage højde for dynamisk indhold, da man kan sætte websiden sammen af mindre bidder. Hvis for eksempel en forside kun ændrer sig få gange i løbet af en dag, men skal indeholde en bannerslynge, som viser et nyt banner ved hver forespørgsel, kan den del af siden, som kun ændrer sig med længere intervaller gemmes. Dermed er det kun den del af koden, som generer banneret, der skal opdateres dynamisk.

Læses lige nu

    AL Sydbank A/S (tidligere Arbejdernes Landsbank)

    Afdelingschef til GDPR & Tech Regulation

    Sydjylland

    Danoffice IT

    Infrastructure Specialist

    Midtjylland

    KMD A/S

    Senior Test Consultant

    Københavnsområdet

    Everllence

    Software Engineer

    Københavnsområdet

    Event: Cyber Security Festival 2026

    Sikkerhed | København

    Mød Danmarks skrappeste it-sikkerhedseksperter og bliv klar til at planlægge og eksekvere en operationel og effektiv cybersikkerhedsstrategi, når vi åbner dørene for +1.700 it-professionelle. Du kan glæde dig til oplæg fra mere end 70 talere og møde mere end 50 leverandører over to dage.

    18 & 19 november 2026 | Gratis deltagelse

    Navnenyt fra it-Danmark

    Netip A/S har pr. 1. marts 2026 ansat Ajanta Holland Christensen som Sales Manager ved netIP's kontor i Aarhus. Han kommer fra en stilling som Account Manager hos Orange Cyberdefense. Nyt job
    Khaled Zamzam, er pr. 1. marts 2026 ansat hos Immeo som Consultant. Han er nyuddannet i Informationsteknologi fra DTU. Nyt job
    Immeo har pr. 1. marts 2026 ansat Theo Lyngaa Hansen som Consultant. Han kommer fra en stilling som Data Manager hos IDA. Han er uddannet i Business Administration & Data Science. Nyt job
    Pentos har pr. 2. juni 2025 ansat Erik Ebert som Country Manager. Han skal især beskæftige sig med udvidelsen af Pentos til Danmark og Norden. Det kræver bl.a. etablering af et lokalt leverance team og SAP Partnerskab. Han kommer fra en stilling som Senior Director hos Effective People. Han har tidligere beskæftiget sig med HR systemer baseret på SAP SuccessFactors hos en række danske større og mellemstore virksomheder. Nyt job

    Erik Ebert

    Pentos