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

Driftmiljön för WordPress – Vart landade vi?

  • 1 mars 2017 10:59
  • Publicerat av: Per Lundin

Innan vi påbörjade införandet av WordPress som standardplattform i Sundsvalls kommun tog vi fram en teknisk målbild för hur plattformens driftmiljö ska se ut. I syfte att skapa en resurseffektiv driftmiljö som är optimerad utifrån det faktiska behovet.

Utgångspunkten – Den tekniska målbilden

Den målbild vi ritade upp byggde 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 byggde 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 testade, utifrån det som framkommit från andra införanden.

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.

Slutlig teknisk lösning

Den slutliga lösningen som vi landade i skiljer sig en hel del från den standardiserade bild som framkom under omvärldsbevakningen, och som var grunden till den initiala målbilden.

Framförallt konstaterade vi att komplexiteten i miljön kunde dras ned drastiskt då flera komponenter inte visade sig tillföra den nytta som beräknats utifrån våra behov. På detta vis blev miljön enklare att både drifta och förvalta över tid, samtidigt som vi håller möjligheten öppen att utöka och skala miljön om ett behov uppkommer i framtiden.

I nedanstående bild illustreras den slutliga arkitekturen för vår WordPress miljö:

Resultat i jämförelse med målbild

Nedan beskrivs de val vi gjorde rörande de komponenter som ursprungligen fanns med i målbilden.

Samtliga prestandamätningar som refereras till är genomförda med hjälp av Apache JMeter och Apache Benchmarking.

Varnish

Detta är den komponent som enskilt förbättrade prestandan absolut mest. Genom att cacha innehållet mot de anslutande klienterna minskade tiden att visa webbplatsen markant, samtidigt som lasten minskade på WordPress och MariaDB.

WordPress

WordPress valde vi att behålla som en instans och inte dela upp i en primär instans och en för endast WordPress Admin (WP-Admin). Istället kunde samma säkerhet uppnås genom att använda befintlig funktionalitet i Linux där vi styr att endast vissa IP-adresser får nå WP-Admin. Med denna funktionalitet styrde vi att endast inloggningar via koncernens säkerhetslösning var godkända mot WP-Admin.

Med denna lösning upprätthåller vi samma säkerhetsnivå för inloggningar som vi har i övrigt inom koncernen, samtidigt som vi minskade komplexiteten i WordPress miljön.

Memcached

Memcached såg vi ingen större effekt utav, vår bedömning är att Memcached kan ge ett stort värde om webbplatserna innehåller funktioner som genererar väldigt långa databasfrågor eller komplexa databasfrågor som tar tid att köra. Men de webbplatser som koncernen planerar att bygga har inte den typen av komplexitet och därmed ger inte Memcached något större värde.

Därför valde vi att skala bort Memcached ur slutlig lösning.

HyperDB/MariaDB

I den initiala målbilden hade vi en klustrad databasmiljö med HyperDB för att hantera detta. Vi valde dock bort lösningen med klustrad databasmiljö av två primära skäl:

  • Det gav ingen större prestandaökning för oss då vi inte har så mycket databasläsning eller komplexa frågor (se även Memcached)
  • Kravställningen som finns idag rörande tillgänglighet på webbplatserna är av den karaktär att redundans och klustring inte är motiverat. Databasen körs ändå i en virtuell servermiljö där återställning går snabbt att göra om fel uppstår.

Så den slutliga lösningen består av en enkel MariaDB databas på en separat server.

Övergripande arkitektur för WordPress

Nedan följer den övergripande slutliga lösningen för produktionsmiljön för WordPress, inklusive dess beroenden till kringliggande infrastruktur: