Overblik
De fleste websteder har store mængder indhold, der forbliver uændret eller kun sjældent ændres efter offentliggørelsen. Og hver gang der anmodes om det fra webserveren, uanset om det er ændret eller ej, behandles det igen og overføres til klienten, hvilket unødigt bruger værdifulde systemressourcer og netværksbåndbredde. Efterhånden som dit websted eller din applikation bliver mere populær, vil der blive stillet større krav til din server om at behandle indhold, der, selv om det er dynamisk genereret, er statisk.
Det er ikke en effektiv udnyttelse af ressourcerne, og det vil i sidste ende ende koste dig mange penge, da du skal installere mere hardware for at kunne følge med belastningen. Det er her, caching kommer ind i billedet. Lad os ikke spilde CPU-cyklusser eller RAM-programmer på at behandle tidligere tilgået indhold, som sandsynligvis ikke vil ændre sig inden for et bestemt tidsrum. I stedet serverer vi forbehandlet indhold, der er midlertidigt gemt på serveren eller i webbrowserens cache. Og først når indholdet er blevet ændret, eller der er gået et bestemt tidsrum, vil vi behandle det ønskede indhold igen.
Konfigurer caching i Apache
Apache leveres med tre moduler til caching af indhold, det ene aktiverer det, og de resterende to bestemmer, hvor cache-lageret findes – på disk eller i hukommelsen. Det afhænger af dine tilgængelige hardwareressourcer og ydelseskrav, hvilket modul du skal bruge til cache-lageret.
Servering fra disk er langsomt, men mindre dyrt. Servering fra hukommelsen er hurtig, men dyr – både i omkostninger og i ressourceforbrug. Du kan dog øge diskcachelagringens ydeevne ved at placere den på SSDFLASH-lagring i stedet for på en konventionel spinningdisk.
- Sørg for, at cache_modulet indlæses af Apache, ved at kontrollere, at følgende linje findes i Apaches serverkonfigurationsfil, ukommenteret.
LoadModule cache_module modules/mod_cache.so
- For diskcaching skal du sikre, at disk_cache_modulet indlæses af Apache. Kig efter følgende linje, ukommenteret.
LoadModule disk_cache_module modules/mod_disk_cache.so
- Føj følgende linjer til enten Apaches serverkonfigurationsfil (for global) eller inde i et VirtualHost-direktiv (lokaliseret i programmet).
CacheEnable disk /CacheRoot /webapps/cache/app1CacheDefaultExpire 3600CacheDisable /wp-admin
CacheEnable disk / Unable caching to disk for relative directory “/”.
Cacheroot Angiv cache-lagringsmappen, hvor alt cachet indhold skal gemmes.
CacheDefaultExpire Angiv standardudløbsdatoen, relativt til den oprindelige anmodningsdato, i sekunder.
CacheDisable Dækker caching for relative stier, der følger indstillingen. Følsomme områder og områder, der ikke bør cachelagres, bør tilføjes her.
Indstilling af indholdsudløb
Caching kræver en udløbsdato, for at det fungerer. Uden en udløbsdato på dit indhold kan cachen ikke afgøre, om det er forældet eller ej.
Brug Apaches Mod_Expires
Dette modul giver dig mulighed for at definere udløbsdatoer for dit indhold, som helhed eller individuelt baseret på type eller matchende streng.
- Sørg for, at modulet bliver indlæst i Apache. Åbn serverkonfigurationsfilen (httpd.conf i CentOS), og kig efter denne linje. Fjern kommentaren, hvis den er kommenteret med et ‘#’.
LoadModule expires_module modules/mod_expires.so
- Føj følgende linjer til enten Apache-serverkonfigurationen, en virtuel værtskonfiguration, et katalogdirektiv eller .htaccess, afhængigt af hvor du vil have indstillet din cachingpolitik.
<IfModule mod_expires.c> ExpiresActive On ExpiresDefault "access plus 1 day"</IfModule></pre>
ExpiresActive On Aktiverer mod expires.
ExpiresDefault Sæt standardudløbsdatoen for alt indhold. Adgang plus 1 dag indstiller udløbstiden til indholdets adgangstid + 1 dag, hvilket betyder, at det vil blive lagret i cache i 24 timer.
- Hvis du ønsker at tildele forskellige udløbsværdier til bestemte indholdstyper, kan du bruge indstillingen ExpiresByType ud over eller uden indstillingen ExpiresDefault. Her er et par eksempler:
<IfModule mod_expires.c> ExpiresActive On ExpiresDefault "access plus 1 day" ExpiresByType image/jpg "access plus 5 days" ExpiresByType image/jpeg "access plus 5 days" ExpiresByType image/gif "access plus 5 days" ExpiresByType image/png "access plus 5 days" ExpiresByType text/css "access plus 1 month" ExpiresByType application/pdf "access plus 1 month" ExpiresByType text/x-javascript "access plus 1 month" ExpiresByType application/x-shockwave-flash "access plus 1 month" ExpiresByType image/x-icon "access plus 1 year"</IfModule>
Brug HTTP-headers i webapplikationen
Forfaldsdatoer og datoer for sidste ændring kan defineres af webapplikationen ved hjælp af HTTP Header-parametre. Dette giver udviklerne eller programmet kontrol over indholdets friskhed. Hvordan du gør det, afhænger af din applikation.
- HTML
Brug metatagget, og definér indholdets alder. I eksemplet nedenfor skal du indstille cachen til privat (kun den anmodende klient) og den maksimale alder til 1 time (3600 sekunder).<meta http-equiv="Cache-control" content="private,max-age:3600"> - PHP
Brug funktionen Header() til at indstille indholdsalderen i dokumenthovedet.header("Cache-Control: private, max-age=3600");
Cache indhold, der ikke udløber
I nogle tilfælde har du brug for at cache indhold, der ikke har en udløbsdato indstillet. Som tidligere nævnt er udløbsdatoer som standard et krav for, at cachingmekanismen kan fungere. Vi kan dog instruere Apache til at tilføje en standardudløbsdato til indhold, der ikke har en defineret udløbsdato, og cache det. CacheIgnoreNoLastMod giver os mulighed for at gøre dette.
- Føj indstillingen CacheIgnoreNoLastMod med værdien On til den placering, hvor du har aktiveret caching – Apaches serverkonfigurationsfil eller en konfigurationsfil for virtuelle værtshuse.
CacheEnable disk /CacheRoot /webapps/cache/app1CacheDefaultExpire 3600CacheDisable /wp-adminCacheIgnoreNoLastMod On
Forebyg browsere fra at cache indhold
Problemet med ovenstående cachingkonfigurationer er, at indholdet af dit program cachelagres to steder: på klienten og på serveren. Hvis du opdaterer dit indhold og ønsker, at brugeren skal se det med det samme, kan de muligvis ikke se det, hvis deres lokalt cachelagrede version ikke er udløbet. Du kan forkorte udløbstiden, men så kan du måske ødelægge formålet med caching helt.
Tag i stedet fuld kontrol over caching ved kun at aktivere den på serveren. Tving webbrowseren til at hente indholdet fra serveren ved hver forespørgsel, men servér f.eks. forbehandlet Java- eller PHP-indhold, medmindre indholdet er blevet ændret. Dette sikrer, at brugeren altid ser den nyeste version, samtidig med at der ikke spildes CPU-cykler eller RAM-ram ved unødig genbehandling.
- Føj indstillingen CacheIgnoreCacheControl til den placering har caching aktiveret – Apaches serverkonfigurationsfil eller en virtuel værts konfiguration – med en værdi på On . Dette får Apache til at ignorere anmodninger om opdatering af browserindhold. Alt indhold vil blive serveret fra serverens cache, hvor det er muligt, indtil den er udløbet.
CacheEnable disk /CacheRoot /webapps/cache/app1CacheDefaultExpire 3600CacheDisable /wp-adminCacheIgnoreNoLastMod OnCacheIgnoreCacheControl On
- Save your changes.
- Restart Apache for at anvende dine ændringer.
WordPress og andre programframeworks
Frameworks, som WordPress’ og dem, der ligner CodeIgniter, dirigerer alt indhold gennem Index.php. Afhængigt af hvordan du har skrevet dine mod_rewrite-regler, vil dit cachede indhold blive vist forkert. Du kan opleve, at indholdet for en anmodet side, kategori osv. vises i stedet for det, der faktisk blev anmodet om.
For at bekæmpe dette skal vi sikre, at Apaches cache tager højde for de parametre, der er vedhæftet i slutningen af index.php, når indholdet cachelagres og trækkes. Ændre Rewrite-reglen for index.php, som det ses i eksemplet nedenfor.
# WordPress Permalink rewritesRewriteBase /RewriteRule ^index.php$ – RewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteRule ^(.*)$ /index.php/