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

    Annonce

    Gyldendal A/S

    Erfaren udvikler med AI-fokus

    Københavnsområdet

    KMD A/S

    Senior SAP Architect

    Københavnsområdet

    Forsvarsministeriets Materiel- og Indkøbsstyrelse

    Cyberdivisionen søger IT-supporterelever til Lokal IT på Aalborg Kaserne

    Nordjylland

    Annonceindlæg fra Pax8

    Den største barriere for AI er ikke teknologi - men at bevise dens forretningsværdi

    Ny leverancemodel gør det lettere og hurtigere for partnere at konfigurere præcis den AI-løsning, der giver kunderne et hurtigere og konkret afkast.

    Navnenyt fra it-Danmark

    Elbek & Vejrup A/S har pr. 1. august 2026 ansat Nathalie Kajberg Knudsen som Supportkonsulent i Evita/Forsyning. Hun skal især beskæftige sig med support af Evita/Forsyning samt bidrage til videreudviklingen af supportsetup på Evita og Appia. Hun kommer fra en stilling som support indenfor Kundeadministration og Afregning hos KMD Easy Energy. Hun har tidligere beskæftiget sig med kørselskoordinering og kørselsledelse hos FKS Slamson og Godik. Nyt job

    Nathalie Kajberg Knudsen

    Elbek & Vejrup A/S

    Sophie Dalsgaard Myhrmann, er pr. 1. september 2026 ansat hos Elbek & Vejrup A/S som Project Manager i Logistik & Produktion. Hun skal især beskæftige sig med projektledelse indenfor logistik og produktion. Hun er nyuddannet cand.it, i IT, kommunikation og Organisation fra Aarhus Univeristet. Nyt job

    Sophie Dalsgaard Myhrmann

    Elbek & Vejrup A/S

    Norriq Danmark A/S har pr. 2. marts 2026 ansat Sarah Strøyer Hove som Consultant ERP. Hun skal især beskæftige sig med de nyeste teknologiske muligheder sammen med forretningsprocesserne. Hun kommer fra en stilling som Business Controller hos NGI A/S. Hun er uddannet hos Professionshøjskolen UCN som markedsføringsøkonom og International Handel og Markedsføring. Hun har tidligere beskæftiget sig med lager og logistik. Nyt job

    Sarah Strøyer Hove

    Norriq Danmark A/S

    Netip A/S har pr. 1. august 2026 ansat Thomas B. Steffensen som Seniorkonsulent ved netIP's kontor i Thisted. Han kommer fra en stilling som Senior IT/OT Network Consultant hos Frontmatec. Nyt job