WooCommerce versnellen – Hoe doe je dat?

WooCommerce versnellen door naar ‘de cloud’ te migreren…

Ooit heb jij besloten te starten met je webwinkel. En mogelijk heeft het even gekost, maar uiteindelijk begon je webshop succes te krijgen. Je hebt een aardig bestand met klanten en in plaats van je webshop ‘erbij’ te doen, heb ik inmiddels je hoofdinkomen uit je winkel.

Prachtig toch!

Maar waar je eerst wakker lag van ’te weinig’ bezoek, lig je nu wakker van ’te veel’ bezoek. Jouw webshop is niet meer vooruit te branden. En in plaats van extra omzet te maken in de drukke perioden, lijken mensen juist dan af te haken. Hoe kan je WooCommerce versnellen?

WooCommerce ‘opschalen’

Ik heb in het verleden verschillende artikelen geschreven over hoe je WooCommerce sneller kan maken. En het is zeker de moeite waard om daar naar te kijken. Een eerste belangrijke keuze is te kiezen voor een goede caching plugin. Een tweede keuze is zo min mogelijk gebruik te maken van extra plugins. Dat is bijvoorbeeld één van de redenen, dat je op deze site tientallen ‘code snippets’ aantreft, waarmee je WooCommerce kan aanpassen zonder plugins.

Ook moet je beslist niet bezuinigen op je hosting. De combinatie ‘WooCommerce / WordPress’ is best een zware combinatie en daar heb je een goede hostingpartij voor nodig.

Maar als je dat allemaal hebt gedaan… en het heeft tijdelijk wel wat snelheidswinst opgeleverd, maar nu het verkeer echt druk wordt, valt de performance terug.

Wat kan je doen om je website weer snel te maken? Je hoster had je al een VPS aangeraden, maar binnen een jaar was je ook uit dat ‘jasje’ gegroeid, en moest je overstappen naar een duurder VPS. Je wordt er allemaal niet vrolijker van.

Eén van de problemen waarmee je te maken krijgt, wanneer je website ’te traag’ wordt op de machine waarop hij staat, is dat WordPress een zogeheten ‘monolithische toepassing’ is.

Dat wil zeggen, dat in de basis, WordPress zo ontworpen is, dat één machine al het werk doet. De webserver zorgt zowel voor het presenteren van de website aan de voorkant, als de afhandeling van allerlei zaken aan de ‘achterkant’ van WordPress.

De makkelijkste manier om te ‘groeien’ is WordPress gewoon op een grotere (en duurdere) machine te plaatsen. Dat zie je in de afbeelding hierboven geïllustreerd. De afbeelding stelt jouw webshop voor, die na ieder succesvol jaar een krachtiger VPS nodig heeft. Meer geheugen, meer CPU’s cores en meer diskruimte.

De rek is eruit

Het nadeel is echter, dat een verdubbeling van capaciteit vaak een exponentiële verhoging van de kosten betekent. Ik heb hieronder een aantal tabellen waarin ik laat zien hoe een verhoging van de capaciteit zich verhoudt met een verhoging van de kosten.

De prijzen zijn de gemiddelden die ik heb genomen over de tarieven van een viertal grote hosting partijen. Sommige van deze partijen hebben de eerste maanden of zelfs een geheel jaar voor een lagere prijs, in dat geval heb ik de reguliere prijs na dat jaar genomen. De prijzen hebben betrekking op ‘unmanaged hosting’, oftewel, jij of jouw systeembeheerder moeten al het werk doen wanneer er iets misgaat met de server.

Wanneer je dit niet zelf kunt, reken er dan op, dat je voor regulier onderhoud aan je VPS je nog zo’n 300 euro per maand extra kwijt bent, wanneer je een druk bezochte server hebt.

Ik heb hierbij de RAM en het aantal CPU’s tegen elkaar uitgezet. Bedenk hierbij, dat je normaal gesproken niet in een rechte lijn horizontaal of verticaal door deze tabel zal ‘bewegen’, maar meer op een diagonale wijze of met ‘paardensprongen’ in een schaakspel.

Wat in bovenstaande tabel niet mee is genomen zijn de kosten van een beheerschil (Plesk of CPanel), off site back ups, de grootte van de hard disk (naarmate je bedrijf groeit zal ook de harddisk mee moeten groeien) en nog een aantal andere factoren die je VPS ‘extra’ duurder maken, naarmate je benodigde capaciteit groeit. Een unmanaged server met een dagelijkse offsite backup, 64 GB RAM, Plesk panel, 512 GB SSD (het minimum wat je nodig hebt, wanneer je deze capaciteit server nodig zou hebben) komt in totaal uit op bijna 1000 euro per maand.

Dat zou allemaal nog de moeite waard zijn, als een verdubbeling van de kosten ook zou betekenen, dat je een verdubbeling van je performance zou krijgen. Maar niets is minder waar. Een een 64GB RAM/8 core VPS gebruikt als een host voor je WooCommerce webshop is niet 31x zo snel als een 2 core 4GB RAM VPS.

Je mag blij zijn, wanneer je de helft haalt.

Je hebt niet altijd de volledige capaciteit nodig!

Wat voor de meeste webwinkeliers ook geldt, is dat WooCommerce versnellen niet eens het hele jaar nodig is. Verschillende van mijn klanten zijn dik tevreden over de capaciteit die hun VPS heeft gedurende 8-10 maanden in het jaar. Het zijn echter die verkoopseizoenen, met name rond de kerst en de start van de zomer, die ineens het aantal bezoekers verdrie- tot tienvoudigen. De vraag is dan, is het de moeite waard om iedere maand bijvoorbeeld 179 euro per maand te betalen, wanneer je de andere maanden meer dan genoeg hebt aan een VPS van 25 euro per maand?

Waardoor word WooCommerce beperkt?

Er is een aantal belangrijke redenen, waarom WooCommerce opschalen en het daadwerkelijke versnellen van WooCommerce niet gelijk op lopen. Eén heeft te maken met het feit dat WooCommerce eigenlijk alles heeft opgeslagen in de database. We kunnen het aantal opvragingen richting database (queries) beperken, door gebruik te maken goede caching mechanismen, maar zelfs dan zitten WordPress en de database elkaar danig in de weg.

Een eerste stap in de goede richting is door niet zomaar je hardware op te schalen. Het is beter de twee taken los van elkaar te zien. En dit dus ook op twee verschillende machines te plaatsen. Op één VPS draait je database, op de andere VPS je webserver en WordPress.

Merk je dat je WooCommerce opschalen een serieuze overweging wordt, onderzoek dan eerst eens, waar de bottleneck zit: Is het in de afhandeling door de webserver, of is de database de boosdoener?

Schaal dan dat VPS op, wat zorgt voor het probleem. Je bent dan een stuk goedkoper uit.

Een betere oplossing?

Je zal ontdekken, dat de hierboven genoemde architectuur al een stuk voordeliger in de kosten wordt. In de afbeelding hierboven betaal je echter nog steeds te veel, wanneer je de extra capaciteit alleen nodig hebt voor de verkooppieken in bepaalde seizoenen.

En wanneer je naast je webshop ook een ‘brick and mortar’ winkel hebt, dat weet jij al precies hoe je dat probleem het best op kan lossen.

De oproepkracht

Stel jij hebt een winkel. En om je nog enige vrije tijd te geven, heb je in jouw winkel ook nog één winkelmedewerker. En zo door het hele jaar heen lukt het jullie prima om samen die winkel te runnen, maar rond de zomervakantie en de kerst heb je het toch extra druk.

Nu kan je natuurlijk je winkelmedewerker vervangen door één die zwaarder is, sneller kan rekenen en meer kan dragen, maar dat is niet de oplossing voor jouw probleem. Waar je veel meer mee geholpen bent, is een tijdelijke extra medewerker. Dat kan een oproepkracht zijn, of iemand die via een uitzendbureau bij je is gekomen, maar de kern van de zaak is, dat je deze medewerker alleen inzet wanneer het werkelijk nodig is.

De rest van het jaar kost deze medewerker je niets… (behalve natuurlijk een kerstpakket voor de bewezen diensten).

Door jouw database en de WordPress instantie ‘los te koppelen’ heb jij eigenlijk alle voorbereidingen gedaan, die nodig zijn om precies datzelfde te bereiken. Maar dat gaat je niet lukken bij de doorsnee website hoster. Hiervoor moet je het hogerop zoeken… en kijken naar de cloud…

Die enge, griezelige cloud!

De meeste mensen krijgen een wat unheimisch gevoel, wanneer ze denken aan ‘de cloud’. Er zijn allerlei griezelverhalen hoe al jouw gegevens ‘gehackt’ kunnen worden ‘in de cloud’.

De werkelijkheid is dat de grote cloud providers veiliger zijn dan welke instantie dan ook, en Amazon, ’s werelds grootste cloud provider, meer en betere veiligheidsmaatregelen heeft dan bijvoorbeeld het Pentagon.

In feite zijn jouw gegevens bij iedere willekeurige niet-cloud georiënteerde hosting provider een stuk minder veilig dan in de Amazon cloud. Laten we ons dus eerst even over dat vooroordeel heen zetten.

Een tweede reden, waarom mensen vaak een unheimisch gevoel krijgen bij het horen van de term ‘cloud’ is omdat het toch wel heel complex is. En dat is waar. Ik kan weinig doen om je van dat gevoel af te helpen, anders dan mijn diensten aan te bieden om met jou eens naar een goede cloudoplossing voor jouw webshop te kijken.

Amazon AWS (Amazon Cloud Services)

De eerste, en nog steeds grootste, cloud provider was Amazon. En ja, dat is dezelfde Amazon die zo bekend geworden is met hun webshop. Want toen Amazon nog (relatief) klein was hadden ze exact hetzelfde probleem waar jij tegenaan liep. En daar hadden ze een oplossing voor nodig. En het aardige was, dat met die oplossing ze direct ook een product hadden ontwikkeld, wat ook voor andere mensen goed van pas kwam. En Amazon Cloud Services was geboren.

Nu is het ondoenlijk om alle diensten van Amazon te beschrijven. Zelf heb ik in 2017 mijn certificaat voor Amazon Solutions Architect Associate behaald en zelfs ik ken slechts de ’toplaag’ van de diensten die AWS aanbiedt.

Maar daar gaat het niet om, het gaat erom, hoe de cloud jou kan helpen met het oplossen van jouw probleem van ’tijdelijk capaciteitsgebrek’. Want wat jij nodig hebt is het ‘schaalbaar maken’ van jouw capaciteit. Schaalbaarheid is het sleutelwoord voor een positieve balans tussen kosten en performance.

Je hebt hier echter één probleem. Je kan niet zomaar WordPress op drie verschillende machines installeren met dezelfde website, verbinden met dezelfde database en hopen dat dit zal werken.

Dat al het namelijk niet. Je kunt namelijk niet (zomaar) drie instanties met dezelfde domeinnaam naast elkaar draaien. Je zou allerlei problemen krijgen.

Bovendien, ‘drie machines naast elkaar laten draaien’ zorgt alleen maar, dat alles nog duurder wordt. En we wilden juist kosten besparen. Hoe lossen we dat op?

Load Balancing

Kijk eens naar de afbeelding hieronder.

Wat je hier ziet is een (eenvoudige) schets van een ‘Virtual Private Cloud’, jouw eigen wolkje aan het uitspansel van Amazon.

Helemaal bovenaan zie je het Internet. En vanuit het Internet kan er maar één ding gebeuren: Mensen zoeken contact met de ‘Load Balancer’.

En die load balancer staat in direct contact met WordPress. Of eigenlijk ‘een aantal instanties van WordPress’.

Want op relatief kleine, virtuele machines in de cloud waar WordPress op draait. Zo’n virtuele machine is eigenlijk exact hetzelfde als jouw VPS, met een aantal kleine verschillen. Het belangrijkste verschil is dat ze zijn opgestart vanuit een zogenaamde ‘image’, een soort ‘blauwdruk’, waarop jouw WordPress site plus de hele omgeving van de nodige systeem software staan geïnstalleerd.

Zo’n blauwdruk -de image- is dus zo’n beetje de ‘opstart USB stick’ voor jouw instance.

Alle drie de instanties in de afbeelding draaien dus dezelfde software. Iedere instantie heeft zijn eigen interne IP adres en een eigen interne domeinnaam. Het externe IP adres is geassocieerd met de Load Balancer.

Iemand die jouw domeinnaam intikt zal dus uitkomen op de ‘Load Balancer’ voor jouw website instanties. Afhankelijk van de beschikbaarheid en de ingestelde regels, zal iemand naar één van de instanties worden doorgestuurd, die op hun beurt weer contact leggen met de database.

De truc zit hem echter daar in, dat jij in kan stellen welke instanties van WordPress/WooCommerce actief moeten zijn.

Zo kan je bijvoorbeeld instellen, dat er standaard altijd één actief moet zijn, maar in bepaalde perioden, of bij een bepaalde drukte meer instanties geactiveerd moeten worden.

In principe betaal je alleen voor de actieve instanties. Omdat je natuurlijk altijd één instantie actief wilt hebben, zorg je dat die éne altijd bereikbaar is (je vaste winkelmedewerker), en dat die andere alleen geactiveerd worden wanneer het druk wordt.

Ook kan je een maximum aantal actieve instanties instellen.

Op deze manier heb je dus altijd ‘voldoende capaciteit’ om aan de webserver kant het capaciteitsprobleem op te lossen.

Maar hoe zit het met de database

Met de database is het iets problematischer. Want van de database kan je in principe geen verschillende instanties laten draaien. Dat moet dus op een andere manier worden opgelost.

Van oudsher werkt WordPress/WooCommerce samen met MySQL. Van MySQL is er ooit een ‘zijtak’ ontstaan die luistert naar de naam ‘MariaDB’. En dit zijn de twee databases, waarmee WordPress goed samen kan werken.

Nu biedt Amazon deze databases ook gewoon aan als ‘Images’ en het is dus geen enkel probleem om één van deze twee te gebruiken. Maar er is ook nog een andere dienst die Amazon aanbiedt, die net iets interessanter is.

Dat is AWS RDB, wat staat voor ‘Relational Databases’. Het is een managed database server. En deze service is eigenlijk wel heel interessant. Want in plaats van zelf voor het beheren van de database te moeten zorgen, doet Amazon dit helemaal voor jou: De backups worden gemaakt en ook de updates van alle software wordt helemaal door Amazon verzorgd.

Amazon biedt op deze manier drie ‘WordPress compatible’ databases aan. Drie? Maar er waren er toch maar twee, die compatible met WordPress zijn?

In de ‘wijde wereld’ is dat inderdaad zo, maar Amazon heeft een eigen relationele database ontwikkeld met een paar leuke extra eigenschappen. En het aardige is, deze eigen Database (Aurora) komt in twee comptabiliteitsversies: MySQL/MariaDB compatible of PostgreSQL compatible.

Maar wat heeft Aurora nu extra aan te bieden?

Ongeveer 5x sneller dan MySQL/MariaDB

Zonder extra maatregelen te hoeven nemen is Aurora zo’n 5x sneller dan de andere databases waar WordPress mee samen wil werken. Je hebt dus direct een krachtig werkpaard te pakken, ook wanneer je geen gebruik wilt maken van de andere extra mogelijkheden die Aurora biedt.

Aurora is ‘instantieerbaar’

Het is mogelijk om meerdere instances van Aurora te draaien. Waarom lukt dit met Aurora wel en met bijvoorbeeld MySQL niet? De grap zit hem in het feit, dat Aurora niet alle instances ‘gelijk’ maakt.

In de meeste databases zal het veel vaker gebeuren, dat gegevens worden opgevraagd, dan dat gegevens moeten worden weggeschreven. Bijvoorbeeld in WordPress/WooCommerce zal je verschillende pagina’s in een webshop bezoeken. Hiervoor moeten gegevens uit de database worden opgehaald. Er worden pas gegevens weggeschreven, op het moment dat je bijvoorbeeld een bestelling plaatst.

Wat Aurora doet, is dat er een aantal instanties wordt aangemaakt (in ons voorbeeld weer drie, maar in de praktijk kan het vrijwel ieder aantal zijn, afhankelijk van wat je ingesteld hebt), waarbij één instantie een ‘Read/Write’ instantie is (RW) en de andere instanties zijn ‘Read-Only’ (RO). Alle wijzigingen aan gegevens die aan de RW instantie worden doorgegeven zullen met een kleine vertraging (fracties van seconden tot enkele seconden, afhankelijk van de drukte) worden doorgegeven aan de andere instanties.

Dit is met name voor content management systemen en webshops een heel gunstige strategie, omdat er veel vaker gegevens zullen worden opgevraagd, dan weggeschreven.

Aurora heeft een zeer gunstig ‘backup beleid’

Het grote nadeel van een drukke webshop, is dat je eigenlijk niet genoeg backups kan maken. Want op het moment dat er iets gebeurd met je database, en moet een backup terug zetten, dan raak je altijd de gegevens van het moment tussen de laatste back up en het moment van de crash kwijt.

Nu maakt Aurora iedere dag zelf een backup en kan jij zelf ook nog eens net zo vaak als je wilt een eigen back up (‘snapshot’) maken. Bijvoorbeeld handig om net voor gepland onderhoud te doen.

Maar daarnaast maakt Aurora na iedere schrijfactie ook een back-up van de ‘logs’, bestanden waarmee de laatste acties op de database kunnen worden nagespeeld.

Het is daarom met Aurora mogelijk om tot maximaal 35 dagen terug te gaan naar de toestand van de database op ieder gewenst moment in de tijd.

Cross Region Replication

Waarschijnlijk zal je het nooit nodig hebben, en het kost wel extra, maar wil je de bijna-zekerheid, dat je database nooit langer dan 1 minuut off line zal zijn, dan kan je zelfs kiezen voor ‘Cross Region replication’. De gegevens van jouw database worden naar een ander datacenter naar keuze gerepliceerd. En ingeval van een extreme situatie als een aardbeving of een brand in jouw datacenter, zal binnen één minuut jouw database weer online zijn.

Wat kost Aurora?

De kosten van Aurora zijn niet zoals bij bijvoorbeeld een VPS vast te stellen op een bepaald bedrag. Je betaalt immers per instantie, en hoelang die instantie online is. Daarnaast betaal je ook voor de capaciteit van een individuele instantie. Wanneer je begint met de kleinste capaciteit betaal je 4,8 dollarcent per uur. Als je ervan uitgaat, dat een maand ongeveer 750 uur heeft, dan is dat dus zo’n 36 dollar per maand voor een enkele instance. Zouden er constant minimaal 2 instances naast elkaar draaien (dus de DB server heeft het zo druk, dat dag en nacht twee instances nodig zijn), dan wordt dit bedrag verdubbeld. Maar tenzij je wereldwijd zaken doet, is het niet waarschijnlijk, dat je dag en nacht evenveel verkeer hebt.

Failover

De hierboven beschreven configuraties hebben als bijkomend voordeel, dat het mogelijk is om bij het uitvallen van één instantie van de database of de webshop een andere instantie opgestart kan worden om het werk over te nemen. Omdat zo’n instantie eerst opgestart moet worden, zal het enkele minuten tot het moment van uitval duren voor je site weer in de lucht is.

Om dat risico te vermijden kan je er ook voor kiezen om altijd minimaal twee instanties te laten draaien. Op het moment dat de load balancer merkt, dat één van de twee instanties niet meer ‘in de lucht’ is, zal er een nieuwe worden opgestart.

Amazon Lightsail – AWS ‘Light’ in de cloud

Wanneer je het bovenstaande verhaal goed in de oren klinkt, je inmiddels uit het jasje van je shared hosting account bent gegroeid, maar nog niet ’toe’ bent aan een relatief dure VPS server, dan is er nog een leuke andere mogelijkheid.

Amazon biedt onder de naam Lightsail een product aan, wat in principe een kant en klaar ingericht VPS in de cloud is. Deze VPS-en zijn applicatie gericht. Zo is er een image die een ‘ready to run’ WordPress server omgeving aanbiedt.

Wanneer je nog niet eerder gebruik gemaakt hebt van een AWS trial account, dan kan je drie maanden lang gratis gebruik maken van zo’n VPS. Daarna kost het 10 dollar per maand. Wanneer je jouw website, webshop of online leeromgeving door WordXPression laat bouwen, help ik je graag bij het opzetten van jouw aanwezigheid in de cloud.

Een andere manier van denken

Om op een dergelijke manier je webshop online te krijgen en te houden vereist een andere manier van denken. De meeste mensen -inclusief ikzelf- zien de hosting van je website toch in grote maten als een ‘kostenpost’ en minder als een ‘investering’. Het opzetten van je webshop op een manier als hierboven besproken is vooral een investering in een goede bereikbaarheid van je winkel, onder welke omstandigheden dan ook. Maar dan vooral een goede investering, omdat je hierbij bepaald hoeveel je maximaal aan je hosting uit wilt geven. De meeste maanden zal je ontdekken dat eenzelfde bereikbaarheid ook voor (veel) minder geld mogelijk is.

Betaal jij op dit moment meer dan 150 euro per maand aan je VPS en je bent nog steeds niet tevreden over de performance van je website tijdens piekuren, dan kijk ik graag eens samen met jou, wat mogelijke oplossingen voor je zijn.

WP Professionals onder elkaar

Ben jij een WP Professional en heb jij te maken met een klant die helemaal blij is met de webshop die jij voor hem hebt gemaakt, maar heeft hij toch moeite met de performance van die website, dan kan je mij geheel ‘white label’ inhuren om eens samen met jou te kijken naar mogelijke performanceverbeteringen voor je klant. Kijk eens naar mijn ‘Strippenkaart voor WP Professionals‘