Caching med WP Super Cache

WordPress og Drupal er effektive værktøjer til at bygge websites der er lette at vedligeholde og opdatere, men fleksibiliteten koster på serversiden. Inden en webside bliver vist i browseren skal serveren afvikle PHP-kode for at konstruere sidens markup, og der skal foretages databasekald for at fylde siden med indhold. Serveren behandler den samme kode og laver de samme databaseforespørgsler igen og igen, uanset om en webside har ændret sig siden sidst den blev vist eller ej - adskillige gange i sekundet på en travl hjemmeside. I denne artikel kigger vi nærmere på brugen af WP Super Cache til reducere arbejdet med at vise sider der kun sjældent ændrer sig.

Nu kan man selvfølgelig være ligeglad med spildt arbejde på serveren, hvis den ellers er hurtig nok. Mange mindre hjemmesider deler imidlertid serverplads med andre websites, og skal derfor konkurrere med hinanden om serverens ressourcer. Og selv en hurtig server kan blive bragt i knæ hvis antallet af besøgende pludselig mangedobles, f.eks. hvis man bliver omtalt i medierne.

Problemet løser selvfølgelig sig selv - hvis serveren er for længe om at svare, så mister de besøgende på hjemmesiden før eller siden tålmodigheden og finder noget andet at kigge på. Men det vil de fleste gerne undgå, og det giver derfor god mening at se på hvordan forbruget af ressourcer på serveren kan minimeres.

En effektiv strategi er caching. Første gang en website vises skal serveren lave hele arbejdet med at afvikle PHP og lave SQL-forespørgsler, men når siden først er konstrueret og sendt til browseren, så bliver den gemt på serveren i et format der gør den hurtigere at vise næste gang. Fremgangsmåden kan sammenlignes med et standardbrev som et firma sender for at kvittere for modtagelse af en jobansøgning - det kan tage lidt tid at formulere det første brev, men når de næste ansøgninger kommer er det blot et spørgsmål om at rette dato, navn og adresse og skrive brevet ud igen. Ingen grund til at starte med et blankt stykke A4 papir hver gang.

Drupal-brugere kan glæde sig over at support for caching allerede er indbygget i core. Hvis man laver hjemmesider i WordPress skal man installere et caching plugin, typisk enten W3 Total Cache eller WP Super Cache. Vi foretrækker WP Super Cache fordi det er let at installere og konfigurere, men begge er glimrende plugins. Nedenfor gennemgås hvordan WP Super Cache kan konfigureres.

Start med at installere og aktivere WP Super Cache i WordPress. WordPress advarer om at plugin'et skal konfigureres:

http://stickleback.dk/bcknd/wp-content/uploads/WP-Super-Cache.jpg

Klik på "plugin admin page" linket for at konfigurere:

http://stickleback.dk/bcknd/wp-content/uploads/WP-Super-Cache.jpg

Den gule tekst øverst på siden advarer om at WP Super Cache har tilføjet nogle linjer til wp-config.php. I de fleste tilfælde bliver denne advarsel kun vist første gang konfigurationssiden åbnes. Hvis den ikke forsvinder når browseren opdateres, så brug linket "Troubleshooting Guide" for at læse om hvordan problemet kan løses (en typisk årsag er at wp-config.php er skrivebeskyttet).

Vælg "Caching On" og klik på "Update Status". Klik herefter på "Test Cache":

http://stickleback.dk/bcknd/wp-content/uploads/WP-Super-Cache.jpg

Caching er nu aktiv og WP Super Cache har kørt en simpel test der indikerer at alt virker som det skal. (Hvis man kigger i kildekoden på en cachet side i browseren, ser man noget lignende dette i bunden af siden:

<!-- Cached page generated by WP-Super-Cache on 2013-04-30 14:43:12 -->

WP Super Caches "Test Cache" funktion loader forsiden to gange i træk og kigger efter tidspunktet i denne linje. Hvis tidsstemplet er det samme begge gange siden indlæses, så er det en indikation af at caching fungerer som det skal).

Inden man går videre, bør man tjekke websitet igennem og se efter at alting stadig fungerer som det skal. NB! Dette skal gøres uden at være logget ind, da Herefter kan man så komme tilbage og åbne "Advanced" fanebladet for at justere nogle af standardindstillingerne i WP Super Cache:

WP Super Cache Advanced Tab

I "caching" afsnittet kan man se at "Use mod_rewrite to serve cache files" er markeret som "Recommended", mens "Use PHP to serve cache files" er aktiv som standard. Forklaringen er at "Use mod_rewrite ..." i nogle tilfælde kræver manuel redigering af .htaccess filen i roden af WordPress installationen. WP Super Cache vil forsøge at foretage de nødvendige rettelser, men hvis det af den ene eller anden grund ikke lykkes må man selv i gang (WP Super Cache leverer de linjer der skal rettes, så det er en forholdsvis simpel cut-and-paste opgave).

Brugen af PHP til at levere cachede filer kan godt trække tænder ud på serveren, specielt på en delt server der bruger SuPHP. Så hvis man ikke bliver nervøs ved tanken om eventuelt at skulle at rette i .htaccess er det en god ide at skifte til at bruge mod_rewrite.

I "miscellaneous" afsnittet kan man normalt slå alle de punkter til der er markeret med "recommended":

WP Super Cache Misc

Bemærk at "304 Not Modified browser caching" ikke kan bruges hvis man har valgt "mod_rewrite" caching. Hvis man bruger PHP til at levere cachede filer, så kan dette punkt aktiveres ("304 Not Modified" er en del af kommunikationen mellem browser og server. Browsere som Internet Explorer, Chrome m.fl. gemmer kopier af sideindhold lokalt på brugerens computer. En "304" besked fra serveren betyder at siden er uændret siden den sidst blev åbnet, og at browseren derfor ikke behøver downloade den igen).

Hvis punktet "Don't cache pages for known users" er aktiveret, så vil man ikke se cachede sider når man er logget ind. Hvis man vil tjekke hvordan anonyme brugere oplever siden, så skal man huske at logge ud først.

De øvrige punkter under "miscellaneous" bruges til at justere den måde caching fungerer på. Et typisk eksempel er sider der indeholder PHP-kode der skal køre hver gang siden åbnes. Caching vil normalt forhindre dette - afvikling af PHP er jo noget man gerne vil undgå - men det er muligt at markere dele af en side som indhold der ikke skal caches så siden stadig vil fungere (omend langsommere end ellers). Bemærk at dynamisk indhold genereret af JavaScript ikke caches på serveren.

Længere nede på dette faneblad finder man et afsnit med titlen "Expiry Time and Garbage Collection":

WP Super Cache Expiry

Ideen med at angive en udløbstid ("Expiry Time") og et oprydningsinterval ("Garbage Collection") er at begrænse antallet af sider der er gemt i cachen. Første gang en bruger besøger en side, så gemmer WP Super Cache en kopi af siden på serveren. Herefter behøver serveren i princippet aldrig generere denne side igen - hver gang en bruger åbner den i browseren, så kigger serveren i cachen, finder kopien og sender den til browseren. Problemet er bare at cachen over tid vokser sig større og større, og det betyder typisk at den bliver mindre og mindre effektiv. Det er vigtigt at rydde op en gang imellem, så cachen ikke bliver fyldt op med kopier af sider som ingen alligevel interesserer sig for længere.

Cache Timeout angiver hvor længe en side i cachen betragtes som "frisk". Standardværdien er 3600 sekunder, dvs. 1 time.

Scheduler angiver hvor ofte WP Super Cache rydder op i sider der ikke længere er friske. Standardværdien er en gang i timen.

Med standardindstillingerne overlever en cachet side i højst to timer: Antag at cachen er tom, og at oprydningsrutinen kører hver hele time. Kl. 12:01 åbner en bruger forsiden i browseren, og WP Super Cache gemmer en kopi i cachen. Kl. 13:00 kører oprydningsrutinen, men forsidekopien har en levetid på en time og da den kun er 59 minutter gammel er den stadig frisk, så den forbliver på serveren. Kl. 14:00 kører oprydningen igen, og denne gang bliver forsidekopien slettet fra cachen. Næste gang forsiden bliver åbnet i browseren laver serveren en ny kopi, og så fremdeles.

Konfigurationssiden har noget tekst der giver eksempler på hvordan disse værdier kan sættes. Der er nogle modstridende faktorer man skal forholde sig til når man vælger hvor længe cachede sider skal gemmes og hvor ofte der skal ryddes op:

  • En høj værdi i cache timeout betyder at cachede sider gemmes længere, dvs. serveren skal bruge mindre tid på at cache dem igen hvis de hele tiden er i brug. Til gengæld risikerer man at cachen kommer til at indeholde et stort antal sider, og derfor bliver mindre effektiv.
  • Hyppig oprydning holder størrelsen på cachen nede fordi sider der ikke længere er friske hurtigt slettes igen. Til gengæld er selve oprydningsrutinen ressourcekrævende.
I de fleste tilfælde er standardværdierne OK. Over tid kan man eksperimentere med forskellige udløbstider og oprydningsintervaller og se hvad der fungerer bedst i praksis.

Det er i øvrigt værd at bemærke at sider og indlæg der bliver redigeret i WordPress normalt opdateres med det samme i cachen - det er ikke nødvendigt at vente på at cachede sider udløber og slettes for at se dem på websitet. Det er også muligt at rydde cachen manuelt hvis noget driller (se på fanebladet "contents").

WP Super Cache er et effektivt caching plugin som er let at anvende - specielt hvis man accepterer et mindre tab i performance og holder sig fra mod_rewrite caching. Og selv med standardindstillingerne kan det medvirke til at gøre en hjemmeside mere attraktiv for brugerne ved at holde svartiderne nede på et acceptabelt niveau.

Blandt de mere avancerede muligheder i WP Super Cache er brug af et Content Delivery Network som for eksempel Amazon Cloudfront til at forbedre responstiden når hjemmesiden åbnes forskellige steder i verden. Det kigger vi nærmere på i den næste artikel.