Pil höger Pil vänster Pil ned Pil up Kaldender Stäng Ladda ned Redigera Fel Notifikation RSS Sök Stjärna Ladda upp Skriva Blixt Stopp Soptunna Vind Vågor Gran Löv Sol Stuga Vattendroppe Eld Fiskben Position Karta Statistik Glödlampa Naturlig försurning Gift Begränsad miljöpåverkan Stäng Meny Minus Plus Minus med cirkel Plus med cirkel
Hoppa till innehåll

Vägen till en effektiv WordPressmiljö

  • 23 september 2014 21:02
  • Publicerat av: Jari Koponen

I arbetet med införandet av WordPress har vi varit i kontakt med ett antal verksamheter, både offentliga och privata, för att ta reda på deras erfarenheter kring införande och drift av plattformen. Vi har fått ut väldigt mycket från dessa kontakter och är tacksamma för all info och input till vårt införande.

Men en sak som ofta framkommit är att nästintill alla parter flaggat för att deras miljö kanske var något i överkant när det kom till prestanda och skala, om man jämför med det faktiska behovet. De var helt enkelt väldigt ofta överdimensionerade.

En driftmiljö som är optimerad utifrån det faktiska behovet är av stor vikt oavsett vad det gäller för IT-stöd, detta för att uppnå en resurseffektiv användning. Men optimeringen görs även för att minimera komplexitet, då vi alla vet att komplexa lösningar är dyra att förvalta i ett längre perspektiv.

För att uppnå en optimerad miljö väljer vi att införa WordPressmiljön steg-för-steg. Vi har börjat med att ta fram en målbild för hur vi tror att infrastrukturen ska se ut i slutändan, men vi installerar inte allt på ett bräde utan vi inför komponent för komponent och efter varje ändring utför vi lasttester och mäter prestanda.

På detta vis kan vi göra en bedömning utifrån vilken faktisk nytta varje komponent ger, och därigenom kan ta beslut om komponenten verkligen är nödvändig.

Målbild

Den målbild vi ritat upp bygger på information från flera olika verksamheter, där vi snabbt fick en relativt standardiserad bild över hur man bör sätta upp en storskalig WordPress lösning. Det visade sig att samtliga parter vi pratade med, oavsett storlek, hade valt att konstruera sina driftmiljöer på ett nästintill identiskt sätt, det enda som skiljde var skala (antal servrar för varje funktion etc) samt vissa produktval.

Målbilden bygger på följande komponenter:

  • Varnish för cachening av innehåll till anslutande klienter
  • Memcached för cachening av databasläsningar
  • HyperDB för att hantera läsning och skrivning mot databasmiljön (en redundant databasmiljö är inritad för att illustrera HyperDBs funktion, kör man utan redundant databasmiljö behövs inte HyperDB överhuvudtaget)

Nedanstående målbild illustrerar alltså övergripande de produktval vi testar, utifrån det som framkommit från andra införanden. Samtliga produktval är öppna lösningar (öppen källkod). Slutlig skala samt exakt vilka komponenter som kommer att krävas kommer vi testa oss fram till.

Serverarkitektur_ WordPress

Det som kan kompletteras till ovanstående bild är att många även placerat en lastbalanserare framför WordPress, både för prestanda men även för så kallad SSL Offloading, eller helt enkelt för att kunna köra krypterad trafik även till siter inom en multisite-installation av WordPress. De flesta använder dessutom MySQL och inte MariaDB som står angiven i bilden.

Vi kommer naturligtvis återkomma med ett blogginlägg om den slutliga driftmiljöns uppbyggnad och resultatet av vårt steg-för-steg införande! Har du synpunkter eller input kring ovanstående målbild eller vårt arbete är du välkommen att kontakta någon av nedanstående personer:

Per Lundin
Projektledare, Införande av WordPress
per.lundin@sundsvall.se

Jari Koponen
IT-infrastrukturarkitekt
jari.koponen@sundsvall.se
@ijkop på Twitter