Sådan konfigureres Apache Content Caching på Ubuntu 14.04

Hvad er Caching?

Caching er en metode til at forbedre serverens ydeevne ved at tillade, at almindeligt efterspurgt indhold gemmes midlertidigt på en måde, der giver hurtigere adgang. Dette fremskynder behandling og levering ved at skære nogle ressourcekrævende operationer væk.

Gennem oprettelse af effektive caching-regler vil indhold, der er egnet til caching, blive lagret for at forbedre svartider, spare ressourcer og minimere belastning. Apache tilbyder en række forskellige caches, der er egnede til at fremskynde forskellige typer operationer. I denne vejledning vil vi diskutere, hvordan du konfigurerer Apache 2.4 på Ubuntu 14.04 ved hjælp af de forskellige cachingmoduler.

For at lære mere om udvikling af generelle cachingstrategier kan du læse denne artikel.

En introduktion til caching i Apache

Apache kan cache indhold med forskellige niveauer af sofistikerethed og skalerbarhed. Projektet opdeler disse i tre grupper efter den metode, som indholdet cachelagres på. Den generelle opdeling er:

• File Caching: Den mest grundlæggende caching-strategi, denne åbner simpelthen filer eller fildeskriptorer, når serveren starter, og holder dem tilgængelige for at fremskynde adgangen.
• Key-Value Caching: Key-Value Caching, der hovedsageligt anvendes til SSL- og autentifikationscaching, anvender en delt objektmodel, der kan gemme elementer, som det er dyrt at beregne gentagne gange.
• Standard HTTP-caching: Den mest fleksible og generelt nyttige cachingmekanisme, dette tretilstandssystem kan gemme svar og validere dem, når de udløber. Dette kan konfigureres med henblik på ydeevne eller fleksibilitet afhængigt af dine specifikke behov.

Et hurtigt kig på ovenstående beskrivelser kan afsløre, at ovenstående metoder har en vis overlapning, men også at det kan være nyttigt at bruge mere end én strategi på samme tid. Hvis du f.eks. bruger et nøgleværdilager til dine SSL-sessioner og aktiverer en standard HTTP-cache til svar, kan du aflaste dine datakilder betydeligt og fremskynde mange indholdsleveringsoperationer for dine klienter.

Nu har du en bred forståelse af hver af Apaches caching-mekanismer, så lad os se nærmere på disse systemer.

File Caching

Generel oversigt

• Primære involverede moduler: mod_file_cache
• Vigtigste anvendelsesområder: Lagring af enten filindhold eller fildeskriptorer, når serveren starter. Det er statiske repræsentationer, der ikke pålideligt kan ændres, før serveren genstartes.
• Funktioner: enkel, forbedrer ydeevnen for langsomme filsystemer
• Ulemper: eksperimentel funktion, reagerer ikke på opdateringer på filsystemet, skal bruges sparsomt for at passe inden for operativsystemets begrænsninger, kan kun bruges på statiske filer

Detaljerne

Modulet mod_file_cache bruges primært til at fremskynde filadgang på servere med langsomme filsystemer. Det giver mulighed for at vælge mellem to konfigurationsdirektiver, der begge har til formål at fremskynde processen med at servere statiske filer ved at udføre noget af arbejdet, når serveren startes, i stedet for når der anmodes om filerne.

Direktivet CacheFile bruges til at angive stien til de filer på disken, som du ønsker at fremskynde adgangen til. Når Apache startes, åbner Apache de statiske filer, der er angivet, og gemmer filhåndteringen i cache, så det ikke er nødvendigt at åbne filen, når der anmodes om den. Antallet af filer, der kan åbnes på denne måde, er underlagt de begrænsninger, der er fastsat af dit styresystem.

Direktivet MMapFile åbner også filer, når Apache startes første gang. MMapFile cacher dog filens indhold i hukommelsen i stedet for kun filhåndteringsenheden. Dette giver hurtigere ydeevne for disse sider, men det har nogle alvorlige begrænsninger. Den opretholder ingen registrering af den mængde hukommelse, den har brugt, så det er muligt at løbe tør for hukommelse. Bemærk også, at børneprocesser vil kopiere al den allokerede hukommelse, hvilket kan resultere i hurtigere udtømning af ressourcerne, end du oprindeligt kan forvente. Brug kun dette direktiv sparsomt.

Disse direktiver evalueres kun, når Apache starter. Det betyder, at du ikke kan stole på, at Apache opfanger ændringer, der er foretaget, efter at den er startet. Brug kun disse på statiske filer, der ikke vil blive ændret i Apache-sessionens levetid. Afhængigt af hvordan filerne ændres, kan serveren blive underrettet om ændringer, men dette er ikke den forventede adfærd og vil ikke altid fungere korrekt. Hvis der skal foretages ændringer i filer, der er overgivet til disse direktiver, skal du genstarte Apache, efter at ændringerne er foretaget.

Sådan aktiverer du filcaching

Filcaching leveres af modulet mod_file_cache. Hvis du vil bruge denne funktionalitet, skal du aktivere modulet.

Når du kører Ubuntu 14.04, vil modulet være installeret, men deaktiveret, når du installerer Apache. Du kan aktivere modulet ved at skrive:

sudo a2enmod file_cache

Bagefter skal du redigere hovedkonfigurationsfilen for at opsætte dine direktiver til caching af filer. Åbn filen ved at skrive:

sudo nano /etc/apache2/apache2.conf

For at opsætte caching af filhåndtag skal du bruge CacheFile-direktivet. Dette direktiv tager en liste over filstier, adskilt af mellemrum, som her:

CacheFile /var/www/html/index.html /var/www/html/somefile.index

Når serveren genstartes, vil Apache åbne de anførte filer og gemme deres filhåndtag i cachen for hurtigere adgang.

Hvis du i stedet ønsker at mappe nogle få filer direkte i hukommelsen, kan du bruge MMapFile-direktivet. Dets syntaks er grundlæggende den samme som det sidste direktiv, idet det blot tager en liste over filstier:

MMapFile /var/www/html/index.html /var/www/html/somefile.index

I praksis vil der ikke være nogen grund til at konfigurere både CacheFile og MMapFile for det samme sæt filer, men du kan bruge dem begge på forskellige sæt filer.

Når du er færdig, kan du gemme og lukke filerne. Kontroller konfigurationsfilens syntaks ved at skrive:

sudo apachectl configtest

Hvis den sidste linje lyder Syntax OK, kan du roligt genstarte din Apache-instans:

sudo service apache2 restart

Apache genstarter og cachelagrerer filindholdet eller handlerne afhængigt af de direktiver, du har brugt.

Key-Value Caching

Generel oversigt

• Primære involverede moduler: mod_socache_dbm, mod_socache_dc, mod_socache_memcache, mod_socache_shmcb
• Indgår understøttende moduler: mod_socache_dbm, mod_socache_dc, mod_socache_memcache, mod_socache_shmcb
• mod_authn_socache, mod_ssl
• Vigtigste anvendelsesområder: lagring af SSL-sessioner eller autentifikationsoplysninger, SSL-hæftning
• Funktioner: delt objektcache til lagring af komplekse ressourcer, kan hjælpe med caching og hæftning af SSL-sessioner, fleksible backends
• Ulemper: har ingen valideringsmekanismer, behov for at konfigurere separat software for mere effektive/fleksible backends, nogle fejl i koden

Detaljerne

Key-value caching er mere kompleks end filcaching og har mere fokuserede fordele. Apaches nøgle-værdi-cache, der også er kendt som en delt objektcache, bruges hovedsagelig til at undgå gentagelse af dyre operationer, der er involveret i opsætning af en klients adgang til indhold, i modsætning til selve indholdet. Specifikt kan den bruges til at cache autentifikationsoplysninger, SSL-sessioner og til at levere SSL-heftning.

I øjeblikket er der nogle problemer med alle udbydere af shared object cache. Henvisninger til problemerne vil blive skitseret nedenfor. Tag disse i betragtning, når du vurderer, om du skal aktivere denne funktion.

Den egentlige caching opnås ved hjælp af et af modulerne for udbydere af caching af delte objekter. Disse er:

• mod_socache_dbm: Denne backend bruger den simple dbm databasemotor, som er et filbaseret nøgle-værdilager, der gør brug af hashing og spande med fast størrelse. Denne udbyder lider af nogle hukommelseslækager, så i de fleste tilfælde anbefales det at bruge mod_socache_shmcb i stedet.
• mod_socache_dc: Denne udbyder bruger distcache-sessionscaching-softwaren. Dette projekt er ikke blevet opdateret siden 2004 og er ikke engang pakket til nogle distributioner, så brug det med en sund dosis forsigtighed.
• mod_socache_memcache: Dette bruger memcache-distribueret hukommelsesobjektcache til opbevaring af elementer. Dette er den bedste mulighed for en distribueret cache mellem flere servere. I øjeblikket udløber posterne ikke korrekt, men der er blevet lagt en patch til stammen i Apaches versionskontrol, som løser problemet.
• mod_socache_shmcb: I øjeblikket er dette den bedste mulighed for caching af nøgleværdier. Dette cacher til en cyklisk buffer i delt hukommelse, som vil fjerne poster, når den bliver fuld. Den kvæles i øjeblikket ved poster på over 11k i størrelse.

Sammen med de ovennævnte providermoduler vil der være behov for yderligere moduler afhængigt af de objekter, der cachelagres. For eksempelvis at cache SSL-sessioner eller konfigurere SSL-hæftning skal mod_ssl være aktiveret, hvilket vil give henholdsvis SSLSessionCache og SSLStaplingCache-direktiverne. På samme måde skal modulet mod_authn_socache aktiveres for at konfigurere caching af autentificering, så direktivet AuthnCacheSOCache kan indstilles.

Sådan aktiverer du nøgleværdicaching

Med ovenstående fejl og forbehold i tankerne, hvis du stadig ønsker at konfigurere denne type caching i Apache, skal du følge med nedenfor.

Den metode, der anvendes til at konfigurere nøgleværdicachen, afhænger af, hvad den skal bruges til, og hvilken udbyder du bruger. Vi gennemgår det grundlæggende for både autentifikationscaching og SSL-sessionscaching nedenfor.

I øjeblikket er der en fejl i forbindelse med autentifikationscaching, som forhindrer, at der overføres argumenter til cache-udbyderen. Så alle udbydere, der ikke giver standardindstillinger at falde tilbage på, vil have problemer.

Authentifikationscaching

Authentifikationscaching er nyttigt, hvis du bruger en dyr autentifikationsmetode, f.eks. LDAP- eller databaseautentifikation. Disse typer operationer kan have en betydelig indvirkning på ydeevnen, hvis backend’en skal rammes hver gang, der foretages en godkendelsesanmodning.

Indstilling af caching indebærer ændring af din eksisterende godkendelseskonfiguration (vi vil ikke dække, hvordan du konfigurerer godkendelsen i denne vejledning). Selve ændringerne vil være stort set de samme uanset backend-godkendelsesmetoden. Vi bruger mod_socache_shmcb til vores demonstration.

Først skal du aktivere authn_socache-modulet og mod_socache_shmcb-providermodulet ved at skrive:

 
sudo a2enmod authn_socache
 
sudo a2enmod socache_shmcb
 

Åbn din Apache-hovedkonfigurationsfil, så du kan angive denne shared cache-backend til brug med autentificering:

sudo nano /etc/apache2/apache2.conf

Indenfor, mod toppen af filen, skal du tilføje AuthnCacheSOCache-direktivet. Angiv, at shmcb skal bruges som udbyder. Hvis den tidligere omtalte fejl, der forhindrer optionsoverdragelse, er rettet, når du læser dette, kan du angive en placering og størrelse for cachen. Tallet er i bytes, så det kommenterede eksempel vil resultere i en cache på 512 kilobyte:

AuthnCacheSOCache shmcb# If the bug preventing passed arguments to the provider gets fixed,# you can customize the location and size like this#AuthnCacheSOCache shmcb:${APACHE_RUN_DIR}/auth_cache(512000)

Spar og luk filen, når du er færdig.

Næst skal du åbne din konfigurationsside for virtuelle værter, hvor autentificering er konfigureret. Vi antager, at du bruger den virtuelle værtskonfiguration 000-default.conf, men du bør ændre den, så den afspejler dit miljø:

sudo nano /etc/apache2/sites-enabled/000-default.conf

På det sted, hvor du har konfigureret autentificering, skal du ændre blokken for at tilføje caching. Du skal specifikt tilføje AuthnCacheProvideFor for at fortælle den, hvilke autentificeringskilder der skal cachelagres, tilføje en cache-timeout med AuthnCacheTimeout og tilføje socache til AuthBasicProvider-listen foran din konventionelle autentificeringsmetode. Resultaterne vil se nogenlunde sådan ud:

<VirtualHost *:80> . . . <Directory /var/www/html/private> AuthType Basic AuthName "Restricted Files" AuthBasicProvider socache file AuthUserFile /etc/apache2/.htpasswd AuthnCacheProvideFor file AuthnCacheTimeout 300 Require valid-user </Directory></VirtualHost>

Overstående eksempel er for filautentifikation, som sandsynligvis ikke vil have særlig meget gavn af caching. Implementeringen bør dog være meget ens, når der anvendes andre autentifikationsmetoder. Den eneste væsentlige forskel ville være, hvor “file”-specifikationen er i ovenstående eksempel, ville den anden godkendelsesmetode blive brugt i stedet.

Spar og luk filen. Genstart Apache for at implementere dine caching-ændringer:

sudo service apache2 restart

SSL Session Caching

Den handshake, der skal udføres for at etablere en SSL-forbindelse, medfører et betydeligt overhead. Derfor kan caching af sessionsdataene for at undgå dette initialiseringstrin for yderligere anmodninger potentielt undgå denne straf. Den delte objektcache er et perfekt sted til dette.

Hvis du allerede har SSL konfigureret for din Apache-server, vil mod_ssl være aktiveret. På Ubuntu betyder det, at en ssl.conf-fil er blevet flyttet til mappen /etc/apache2/mods-enabled. Dette sætter faktisk allerede caching op. Indeni vil du se nogle linjer som denne:

. . .SSLSessionCache shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)SSLSessionCacheTimeout 300. . .

Det er faktisk nok til at opsætte sessionscaching. For at teste dette kan du bruge OpenSSL’s forbindelsesklient. Type:

openssl s_client -connect 127.0.0.1:443 -reconnect -no_ticket | grep Session-ID

Hvis sessions-id’et er det samme i alle resultaterne, fungerer din sessionscache korrekt. Tryk på CTRL-C for at afslutte tilbage til terminalen.

Standard HTTP Caching

Generel oversigt

• Primære involverede moduler: mod_cache
• Indgår understøttende moduler: mod_cache_disk, mod_cache_socache
• Vigtigste anvendelsesområder: mod_cache_disk, mod_cache_socache
• Caching af generelt indhold
• Funktioner: Kan korrekt fortolke HTTP caching headers, kan revalidere forældede poster, kan implementeres for maksimal hastighed eller fleksibilitet afhængigt af dine behov
• Ulemper: Kan lække følsomme data, hvis de er forkert konfigureret, skal bruge yderligere moduler for at indstille cachingpolitikken korrekt

Detaljerne

HT HTTP-protokollen tilskynder til og leverer mekanismerne til caching af svar hele vejen til levering af indhold. Enhver computer, der berører indholdet, kan potentielt cache hvert element i et vist tidsrum afhængigt af de cachingpolitikker, der er fastsat ved indholdets oprindelse, og computerens egne cachingregler.

Apache HTTP-cachelagringsmekanismen cacher svar i overensstemmelse med de HTTP-cachelagringspolitikker, den ser. Dette er et generelt caching-system, der overholder de samme regler, som enhver mellemliggende server ville følge, der har en finger med i spillet i leveringen. Dette gør dette system meget fleksibelt og kraftfuldt og giver dig mulighed for at udnytte de headere, som du allerede bør indstille på dit indhold (vi dækker, hvordan du gør dette nedenfor).

Apaches HTTP-cache er også kendt som en “three state”-cache. Det skyldes, at det indhold, den har gemt, kan være i en af tre tilstande. Det kan være frisk, hvilket betyder, at det kan serveres til klienterne uden yderligere kontrol, det kan være forældet, hvilket betyder, at TTL for indholdet er udløbet, eller det kan være ikke-eksisterende, hvis indholdet ikke findes i cachen.

Hvis indholdet bliver forældet, kan cachen ved den næste anmodning bekræfte det igen ved at kontrollere indholdet ved oprindelsen. Hvis det ikke er ændret, kan den nulstille friskhedsdatoen og servere det aktuelle indhold. Ellers henter den det ændrede indhold og gemmer det i den tid, der er tilladt i henhold til cachingpolitikken.

Moduloversigt

HT HTTP-cachelogikken er tilgængelig via mod_cachemodulet. Den egentlige caching sker med en af caching-udbyderne. Typisk lagres cachen på disken ved hjælp af mod_cache_disk-modulet, men caching af delte objekter er også tilgængelig via mod_cache_socache-modulet.

mod_cache_disk-modulet cacher på disken, så det kan være nyttigt, hvis du proxyer indhold fra et fjernt sted, genererer det fra en dynamisk proces eller bare forsøger at fremskynde tingene ved at cache på en hurtigere disk, end dit indhold typisk befinder sig på. Dette er den mest velafprøvede udbyder og bør sandsynligvis være dit første valg i de fleste tilfælde. Cachen renses ikke automatisk, så et værktøj kaldet htcacheclean skal af og til køres for at slanke cachen. Dette kan køres manuelt, opsættes som et almindeligt cron-job eller køres som en dæmon.

mod_cache_socachemodulet mod_cache_socache cacher til en af udbyderne af delte objekter (de samme som dem, der blev diskuteret i sidste afsnit). Dette kan potentielt have en bedre ydeevne end mod_cache_disk (afhængigt af hvilken delt cache-udbyder der vælges). Det er dog meget nyere og er afhængig af de delte objektudbydere, som har de tidligere omtalte fejl. Det anbefales at foretage omfattende test, før du implementerer mod_cache_socache-indstillingen.

HTTP-cacheplacering

Apaches HTTP-cache kan implementeres i to forskellige konfigurationer afhængigt af dine behov.

Hvis CacheQuickHandler er indstillet til “on”, vil cachen blive kontrolleret meget tidligt i processen til håndtering af anmodninger. Hvis der findes indhold, vil det blive serveret direkte uden yderligere håndtering. Det betyder, at det er utrolig hurtigt, men det betyder også, at det ikke giver mulighed for processer som f.eks. autentificering af indhold. Hvis der er indhold i din cache, som normalt kræver autentificering eller adgangskontrol, vil det være tilgængeligt for alle uden autentificering, hvis CacheQuickHandler er sat til “on”.

Basisk set emulerer dette en separat cache foran din webserver. Hvis din webserver har brug for at foretage nogen form for betinget kontrol, godkendelse eller autorisering, vil dette ikke ske. Apache vil ikke engang evaluere direktiver inden for <Location>– eller <Directory>-blokke. Bemærk, at CacheQuickHandler som standard er indstillet til “on”!

Hvis CacheQuickHandler er indstillet til “off”, vil cachen blive kontrolleret betydeligt senere i forespørgselsbehandlingssekvensen. Tænk på denne konfiguration som at placere cachen mellem din Apache-behandlingslogik og dit faktiske indhold. Dette vil gøre det muligt at køre de konventionelle behandlingsdirektiver før hentning af indhold fra cachen. Hvis du indstiller dette til “off”, bytter du en smule hastighed til fordel for muligheden for at behandle anmodninger dybere.

Sådan konfigurerer du standard HTTP-caching

For at aktivere caching skal du aktivere mod_cache-modulet samt en af dets caching-providere. Som vi nævnte ovenfor, er mod_cache_disk godt testet, så vi vil stole på det.

Aktivering af modulerne

På et Ubuntu-system kan du aktivere disse moduler ved at skrive:

 
sudo a2enmod cache
 
sudo a2enmod cache_disk
 

Dette vil aktivere caching-funktionaliteten næste gang serveren genstartes.

Du skal også installere apache2-utils-pakken, som indeholder htcacheclean-hjælpeprogrammet, der bruges til at skære ned på cachen, når det er nødvendigt. Du kan installere dette ved at skrive:

 
sudo apt-get update
 
sudo apt-get install apache2-utils
 

Modificering af den globale konfiguration

Det meste af konfigurationen til caching vil finde sted i individuelle virtuelle værtsdefinitioner eller placeringsblokke. Aktivering af mod_cache_disk aktiverer dog også en global konfiguration, som kan bruges til at angive nogle generelle attributter. Åbn denne fil nu for at tage et kig:

sudo nano /etc/apache2/mods-enabled/cache_disk.conf

Med kommentarerne fjernet bør filen se således ud:

<IfModule mod_cache_disk.c> CacheRoot /var/cache/apache2/mod_cache_disk CacheDirLevels 2 CacheDirLength 1</IfModule>

Den IfModule wrapper fortæller Apache, at han kun skal bekymre sig om disse direktiver, hvis mod_cache_disk-modulet er aktiveret. CacheRoot-direktivet angiver den placering på disken, hvor cachen vil blive vedligeholdt. CacheDirLevels og CacheDirLength bidrager begge til at definere, hvordan cache-mappestrukturen vil blive opbygget.

En md5 hash af den URL, der serveres, vil blive oprettet som den nøgle, der bruges til at gemme dataene. Dataene vil blive organiseret i mapper, der er afledt af de indledende tegn i hver hash. CacheDirLevels angiver antallet af underkataloger, der skal oprettes, og CacheDirLength angiver, hvor mange tegn der skal bruges som navn for hvert katalog. Så en hash på b1946ac92492d2347c6235b4d2611184 med de ovenfor viste standardværdier vil blive arkiveret i en mappestruktur på b/1/946ac92492d2347c6235b4d2611184. Normalt vil du ikke have behov for at ændre disse værdier, men det er godt at vide, hvad de bruges til.

Hvis du vælger at ændreCacheRoot-værdien, skal du åbne/etc/default/apache2-filen og ændre værdien afHTCACHECLEAN_PATH, så den passer til dit valg. Denne bruges til at rense cachen med jævne mellemrum, så den skal have den korrekte placering af cachen.

Nogle andre værdier, du kan indstille i denne fil, er CacheMaxFileSize og CacheMinFileSize, som indstiller intervallerne for filstørrelser i bytes, som Apache vil overføre til cachen, samt CacheReadSize og CacheReadTime, som giver dig mulighed for at vente og buffe indholdet, før det sendes til klienten. Dette kan være nyttigt, hvis indholdet befinder sig et andet sted end på denne server.

Modificering af den virtuelle server

Det meste af konfigurationen til caching sker på et mere granulært niveau, enten i definitionen af den virtuelle vært eller i en specifik placeringsblok.

Åbn en af dine virtuelle værtsfiler for at følge med. Vi antager, at du bruger standardfilen i denne vejledning:

sudo nano /etc/apache2/sites-enabled

I den virtuelle værtsblok, uden for en lokationsblok, kan vi begynde at konfigurere nogle af cachingegenskaberne. I denne vejledning antager vi, at vi ønsker at slå CacheQuickHandler fra, så der foretages mere behandling. Dette giver os mulighed for op mere komplette cachingregler.

Vi vil også benytte denne lejlighed til at konfigurere cachelåsning. Dette er et system af fillåse, som Apache vil bruge, når den tjekker ind hos indholdsoprindelsen for at se, om indholdet stadig er gyldigt. I det tidsrum, hvor denne forespørgsel bliver opfyldt, vil det, hvis der kommer yderligere anmodninger om det samme indhold, resultere i yderligere anmodninger til backendressourcen, hvilket kan forårsage belastningsspidser.

Sætningen af en cachelås for en ressource under valideringen fortæller Apache, at ressourcen er ved at blive opdateret. I denne periode kan den forældede ressource serveres med en advarselsheader, der angiver dens tilstand. Vi sætter dette op med en cache lock-mappe i mappen /tmp. Vi tillader maksimalt 5 sekunder, før en lås anses for at være gyldig. Disse eksempler er taget direkte fra Apaches dokumentation, så de burde fungere godt til vores formål.

Vi vil også fortælle Apache, at han skal ignorere Set-Cookie-headere og ikke gemme dem i cachen. Ved at gøre dette vil vi forhindre Apache i ved et uheld at lække brugerspecifikke cookies ud til andre parter. Set-Cookie-headeren vil blive fjernet, før headerene sættes i cache.

<VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined CacheQuickHandler off CacheLock on CacheLockPath /tmp/mod_cache-lock CacheLockMaxAge 5 CacheIgnoreHeaders Set-Cookie</VirtualHost>

Vi skal stadig faktisk aktivere caching for denne virtuelle vært. Det kan vi gøre med CacheEnable-direktivet. Hvis dette er indstillet i en virtuel værtsblok, skal vi angive cachingmetoden (disk eller socache) samt de anmodede URI’er, der skal caches. Hvis du f.eks. vil cache alle svar, kan dette indstilles til CacheEnable disk /, men hvis du kun ønsker at cache svar under /public-URI’en, kan du indstille dette til CacheEnable disk /public.

Vi vil gå en anden vej ved at aktivere vores cache i en specifik lokationsblok. Ved at gøre dette betyder det, at vi ikke behøver at angive en URI-sti til CacheEnable-kommandoen. Enhver URI, der ville blive serveret fra denne placering, vil blive cachelagret. Vi slår også CacheHeader-direktivet til, så vores svarheader vil angive, om cachen blev brugt til at betjene anmodningen eller ej.

Et andet direktiv, vi indstiller, er CacheDefaultExpire, så vi kan indstille en udløbsdato (i sekunder), hvis hverken Expires– eller Last-Modified-headeren er indstillet på indholdet. På samme måde indstiller vi CacheMaxExpire for at sætte et loft over den tid, som elementer vil blive gemt. Vi indstiller CacheLastModifiedFactor, så Apache kan oprette en udløbsdato, hvis den har en Last-Modified-dato, men ingen udløbsdato. Faktoren ganges med tiden siden ændringen for at indstille en rimelig udløbsdato.

<VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined CacheQuickHandler off CacheLock on CacheLockPath /tmp/mod_cache-lock CacheLockMaxAge 5 CacheIgnoreHeaders Set-Cookie <Location /> CacheEnable disk CacheHeader on CacheDefaultExpire 600 CacheMaxExpire 86400 CacheLastModifiedFactor 0.5 </Location></VirtualHost>

Spar og luk din fil, når du har konfigureret alt det, du har brug for.

Kontroller hele din konfiguration for syntaksfejl ved at skrive:

sudo apachectl configtest

Hvis der ikke rapporteres nogen fejl, skal du genstarte tjenesten ved at skrive:

sudo service apache2 restart

Setting Expires and Caching Headers on Content

I ovenstående konfiguration konfigurerede vi HTTP-caching, som er afhængig af HTTP-headers. Men intet af det indhold, vi serverer, har faktisk de Expires– eller Cache-Control-headere, der er nødvendige for at træffe intelligente cachingbeslutninger. For at indstille disse headere skal vi drage fordel af nogle flere moduler.

Modulet mod_expires kan indstille både Expires-headeren og max-age-indstillingen i Cache-Control-headeren. Modulet mod_headers kan bruges til at tilføje mere specifikke Cache-Control-indstillinger for at justere cachingpolitikken yderligere.

Vi kan aktivere begge disse moduler ved at skrive:

 
sudo a2enmod expires
 
sudo a2enmod headers
 

Når vi har aktiveret disse moduler, kan vi gå direkte til at ændre vores virtual host-fil igen:

sudo nano /etc/apache2/sites-enabled/000-default.conf

Modulet mod_expires giver kun tre direktiver. ExpiresActive slår ekspirationsbehandling til i en bestemt kontekst ved at sætte den til “on”. De to andre direktiver ligner hinanden meget. Direktivet ExpiresDefault indstiller standardudløbstiden, og ExpiresByType indstiller udløbstiden i henhold til indholdets MIME-type. Begge disse vil sætte Expires og Cache-Control “max-age” til de korrekte værdier.

Disse to indstillinger kan have to forskellige syntakser. Den første er blot “A” eller “M” efterfulgt af et antal sekunder. Dette indstiller udløbsdatoen i forhold til den sidste gang, indholdet blev henholdsvis “tilgået” eller “ændret”. F.eks. vil begge disse to udløbe indholdet 30 sekunder efter, at det blev tilgået.

ExpiresDefault A30ExpireByType text/html A30

Den anden syntaks giver mulighed for en mere udførlig konfiguration. Den giver dig mulighed for at bruge andre enheder end sekunder, som er lettere for mennesker at beregne. Den bruger også det fulde ord “adgang” eller “ændring”. Hele udløbs-konfigurationen skal holdes i anførselstegn, som her:

ExpiresDefault "modification plus 2 weeks 3 days 1 hour"ExpiresByType text/html "modification plus 2 weeks 3 days 1 hour"

Til vores formål indstiller vi blot en standardudløbsdato. Vi starter med at indstille den til 5 minutter, så hvis vi laver en fejl, mens vi bliver fortrolige, vil den ikke blive gemt på vores klienters computere i ekstremt lang tid. Når vi er mere sikre på vores evne til at vælge politikker, der passer til vores indhold, kan vi justere dette til noget mere aggressivt:

<VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined CacheQuickHandler off CacheLock on CacheLockPath /tmp/mod_cache-lock CacheLockMaxAge 5 CacheIgnoreHeaders Set-Cookie <Location /> CacheEnable disk CacheHeader on CacheDefaultExpire 600 CacheMaxExpire 86400 CacheLastModifiedFactor 0.5 ExpiresActive on ExpiresDefault "access plus 5 minutes" </Location></VirtualHost>

Dette vil sætte vores Expires-header til fem minutter i fremtiden og indstille Cache-Control max-age=300. For at forfine vores cachingpolitik yderligere kan vi bruge Header-direktivet. Vi kan bruge merge-indstillingen til at tilføje yderligere Cache-Control-indstillinger. Du kan kalde dette flere gange og tilføje de yderligere politikker, som du ønsker. Tjek denne vejledning for at få en idé om de cachingpolitikker, du gerne vil indstille for dit indhold. I vores eksempel indstiller vi bare “public”, så andre caches kan være sikre på, at de har lov til at gemme kopier.

For at indstille ETags til statisk indhold på vores websted (til brug for validering) kan vi bruge FileETag-direktivet. Dette vil fungere for statisk indhold. For dynamisk genereret indhold vil dit program være ansvarlig for korrekt at generere ETags.

Vi bruger direktivet til at indstille de attributter, som Apache vil bruge til at beregne Etag. Dette kan være INode, MTime, Size eller All afhængigt af, om vi ønsker at ændre ETag, når filens inode ændres, dens ændringstidspunkt ændres, dens størrelse ændres eller alt det ovenstående. Du kan angive mere end én værdi, og du kan ændre den nedarvede indstilling i underordnede kontekster ved at sætte et + eller - foran de nye indstillinger. Til vores formål bruger vi bare “all”, så alle ændringer registreres:

<VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined CacheQuickHandler off CacheLock on CacheLockPath /tmp/mod_cache-lock CacheLockMaxAge 5 CacheIgnoreHeaders Set-Cookie <Location /> CacheEnable disk CacheHeader on CacheDefaultExpire 600 CacheMaxExpire 86400 CacheLastModifiedFactor 0.5 ExpiresActive on ExpiresDefault "access plus 5 minutes" Header merge Cache-Control public FileETag All </Location></VirtualHost>

Dette vil tilføje “public” (adskilt af et komma) til den værdi, som Cache-Control allerede har, og vil inkludere en ETag for vores statiske indhold.

Når du er færdig, skal du gemme og lukke filen. Kontroller syntaksen af dine ændringer ved at skrive:

sudo apachectl configtest

Hvis der ikke blev fundet nogen fejl, skal du genstarte tjenesten for at implementere dine caching-politikker:

sudo service apache2 restart

Konklusion

Konfigurering af caching med Apache kan virke som et skræmmende arbejde på grund af de mange muligheder, der er. Heldigvis er det nemt at starte simpelt og derefter vokse, efterhånden som du har brug for mere kompleksitet. De fleste administratorer vil ikke have brug for alle cachingtyperne.

Når du konfigurerer caching, skal du huske de specifikke problemer, du forsøger at løse, for at undgå at fare vild i de forskellige implementeringsvalg. De fleste brugere vil have gavn af i det mindste at opsætte headere. Hvis du proxyer eller genererer indhold, kan det være nyttigt at indstille en HTTP-cache. Caching af delte objekter er nyttig til specifikke opgaver som f.eks. lagring af SSL-sessioner eller autentificeringsoplysninger, hvis du bruger en backend-udbyder. Caching af filer kan sandsynligvis begrænses til dem med langsomme systemer.