Brecht Ryckaert: WordPress schalen op een klein budget
Goeiemorgen allemaal, dat is altijd leuk. Eigenlijk veel introducties zal ik wel licht niet meer moeten geven. Ik ben berecht, sinds gisterenavond blijkbaar ook bekend als de persona Bob. Ik ben ik achter gekomen. Zoals gezegd, ik ben een fanatiekling in WordPress. Ik gebruik het al heel lang, initial voor de bloggen. We worden een eigen blogje opgezet. Na een paar jaar wat meer beginnen rommelen. Je past al eens een thema aan. Je zoekt dus je eigen layout. Denk goed dat de meeste van ons eigenlijk allemaal gestart zijn met WordPress. Dat plug-ins dan een keer een functie hier en daar beginnen aanpassen. Kortom eigenlijk steeds meer daarin gerold. 2008 ben ik terechtgekomen bij Combell, een hostingbedrijf waar ik sinds initial gestart ben als support engineer. Ondertussen senior support engineer. En binnen die functie heb ik mij dan echt zitten specialiseren in uiteraard WordPress. Maar vooral performance and security bij WordPress. Vandaag ga ik spreken over schalen op een klein budget. Er zijn een aantal voorwaarden waarover ik het wil hebben. Dit is een letterlijk screenshot van een omschrijving van een basishostingformule. Een absolute basisformule. Hoe koopste van een niet-nader genoemde bedrijf. En daar zien we eigenlijk al een paar hele belangrijke zaken. Vooral dit, de PHP-workers. Dat wil zeggen dat je ook maar 25 concurrenten bezoekers kan accommoderen. Dat is weinig. Als je grote aandacht krijgt, grote hoeveelheid in trafiek krijgt, dan trek je dat gewoon niet. Het ziet er ongeveer zo uit. Dus als daar een 26e bezoeker op dezelfde moment naar die site probeert te gaan, gaan die eerste 25 netjes verwerkt worden, de 26e krijgen een wit scherm nog steeds te zien dat het aan het laden is en aan het laden is. En pas als de eerste van de 25 verwerkt is, komt er een slotje vrij om de volgende te gaan accommoderen. Wat gebeurt erbij? Als dat er 26 zijn, gaat het één persoon eens wat een trageren laat het hebben. Als dat consistent, seconde na seconde na seconde blijft voorkomen, dan gaat die wachtheid steeds maar oplopen en oplopen totdat je bezoekers timeouts krijgen. En dat wil je echt niet.  Dus om dit te gaan simuleren, met het doel van deze talk, want als je dit wil gaan testen, wat ik vandaag ga uitleggen, ofwel overleg je best eerst met je hosting provider, ofwel zet je iets op op DigitalOcean of wat dan ook, want als je dezelfde hoeveelheden trafiek er naartoe gaat doen, als ik gedaan heb voor deze talk, dan wordt je gewoon geblaklist, want dat is in essentie bijna een dedio, is dat je eigenlijk doet. Dus om het surrealistisch mogelijk te houden, heb ik zelf ook gekozen voor een limit van 25, net zoals op de screenshot van de hostingpartij, met een limit van 28 eveneens, en alles draait eigenlijk lokaal, zoals ook bij heel veel shared hosting, in het geval als database op dezelfde server, webserver op dezelfde server, alles lokaal. Nu, wanneer we samenwerken met grote partijen, die hebben grote budgetten om te schalen. De technieken die ik nu ga uitleggen, is eigenlijk vooral gericht, bijvoorbeeld de vereniging, die is een eenmaal een mediaaandacht, krijgt of een groot evenement op oote zet. Die hebben vaak niet de budgetten om te gaan met grote trafiek. En dan als webbeheerder of als provider, krijg je dan vaak de vraag van de klant. Ja, volgende maand gaan we een evenementje organiseren. Kan je ervoor zorgen dat mijn website de trafiek aan kan, dat ze online blijft. En dan zeggen wij uiteraard allemaal, natuurlijk, hoeveel bezoekers schat je ongeveer? Niet te veel, een paar tienduizend per uur. En de meeste onder ons hebben dan zoiets van even en volledige panic modus. Dus daarom zijn er eigenlijk een aantal stappen die ik ga gebruiken om tot een geoptimaliseerde setup te komen. Het doel daarbij is eigenlijk om op een zeer, zeer laag budget te blijven. We kunnen daarin schalen, maar de setup die ik hier heb is bedoeld om makkelijk enkele tienduizenden per uur uit te kunnen. Hoe gaan we dat gaan testen? Zijn er hier mensen die al van Apache Benchmark gehoord hebben? Oké, één iemand. Dat is top, oké. Nee, dat is goed. Dat wil zeggen dat ik jullie in de andere kant meegeef, ik vind dat fantastisch. Dat is eigenlijk een tool die gebruikt kan worden om lood te simuleren op een website of op een server. Als je een Mac-gebruiker bent, zit het gewoon in de terminal ingewerkt.  Maar je kan het ook gewoon installeren via Appget op Linux of binnen de Linux integratie en Windows tegenwoordig ook. Daarvoor gebruik je gewoon Appget install Apache to Udels. Nu, eens dat we dat geinstalleerd hebben, dan gaan we aan de slag om onze site te testen. In de eerste instantie ga ik ze sequentieel sturen. Dat is een heel belangrijke nuance. Ze sturen duizend bezoekers na elkaar, één per één, naar de website die ik heb opgezet op die Digital Ocean omgeving. Dan doen we eigenlijk met dit commando. Dus A, B, dan min, en. Je gebruikt om het aantal te specifieren en dan geef je eigenlijk de host mee waar je naar toe moet. En dan gaat die beginnen. Ik was eerst van plan om ze eigenlijk met video's te doen, maar het zou te lang duren. Dus ik heb gewoon screenshots genomen en dan toon ik jullie de output. Dus je ziet dat die sequentieel die request eigenlijk gaat verwerken en gaat suurt. En dan krijg ik onze output. Nu, er zijn een aantal dingen die daaruit naar boven komen. Dit zijn eigenlijk de hele belangrijke zaken. Hieruit komt dat eigenlijk onze standard setup zonder enige tweaks of wat dan ook. Op dit moment sequentieel een 7,6 bezoekers per seconde kan accommoderen, kan gaan bedienen. De totaal verwerking van zo'n request is op dit moment een respectieve 130 milliseconden. Nu, dit is ook gewoon een standaard Wordpress installatie, zonder iets bij. Teraard als je daar veel foto's in zit en hebt, gaat dit omhoog gaan. Zoiets zo. En een andere belangrijke factor is ook, onderaan krijg je nog een opleisting van de verwerkingsteden die je gaat zien. De traagste zat zelfs aan iets meer dan een seconde, zoals in die helemaal achteraan de reiselt. Nu, die gaan we, die zal de test eigenlijk gaan herhalen, maar nu voegen we eigenlijk een nieuw argument aan ons commando. In dit geval zeggen we, oké, we sturen nog steeds dezelfde duizend bezoekers, maar we gaan ze in batches, dus in hopen van 200 concurrenten, requesten tegelijkertijd sturen. Zullen we zeggen, echt gewoon, nu dit moment 200 bezoekers naar de site, volgende moment 200 bezoekers naar de site, echt, dat is eigenlijk al een behoorlijke belasting. En dat zien we daar wel wat interessante zaken in. Eerst en vooral, de server houdt zich nog altijd vrij netjes recht.  16,98, ja, request per seconde verwerken, op zich goed, maar als we kijken hiernaar, zien we dat de laatste verzoek eigenlijk 4, ja, een 54 seconden in beslag heeft genomen. Dus het is een bezoeker geweest die 54 seconden heeft moeten wachten tot de pagina volledig geladen is. Daarom beginnen we te merken van, oké, die eerste paar verwerkingen, die zijn best wel oké, die gaan nog vrij snel erdoor komen. Maar naarmate dat het aantal bezoekers gestaagd blijft komen, vertraagt de werking van de server en duurt de request langer. En we zitten hier ook. Time per request zit nu ondertussen al op 58 seconden. Dus dat is in tijden van vandaag niet meer acceptabel voor de bezoekers. Die ben je gewoon kwijt. Dan gaan we nog een beetje verder. Nu gaan we duizend bezoekers in één concurrente batch allemaal tegelijkertijd naar onze server sturen. Heeft iemand een idee wat er gebeurt? Dit. Goede 300 simultane bezoekers geeft ieder gewoon volle komende bruin en gaat die volledig neer. Einde website, bezoekers kunnen niet meer aan. En als je geen goede systeem beheer dat die snel kan schakelen, dan ben je gezien als dit soort trafiek blijft komen. En dit is exact wat we nu willen vermijden met de technieken die ik jullie nu uitleggen. Voor leer dat we daar aan beginnen, is nog even een belangrijke verschil maken. We horen heel veel, opschalen is een mode woord. Scalability is een trend, is een hype. Maar er zijn eigenlijk twee soorten van scaling waar men over spreekt. We hebben scaling up en we hebben scaling out. Om dat duidelijk te maken, ga ik eerst even twee slides tonen. Scaling up of vertical schalen is eigenlijk gewoon, je begort dezelfde server, maar je hoort er meer budget tegenaan om meer ram te krijgen, meer CPU, meer desk, whatever. Het probleem daarmee is dat dat een vrij eindig verhaal is. Want in je server, zelfs al werk je gevirtuaredeerd, kan je op een palpunt geen extra RAM meer toevoegen, geen extra CPU's meer toevoegen, want je komt dan op de limieten van je platform. Scaling out of horizontal schalen is eigenlijk een iets slimmer aanpak, in plaats van de server te verzwaar ga je eigenlijk extra nodus gaan toevoegen, die maar even zwaar zijn als jouw standaard server, maar gezamenlijk kunnen ze wel veel meer verwerken.  En puur naar kosten toe is horizontal schalen eigenlijk interessanter dan vertical schalen. Vooral wanneer je echt naar de hoge limieten toe gaat, dan wordt het bij vertical schalen een zeer dure aangelegenheid, terwijl bij horizontal schalen kan je hetzelfde bereiken met een nog altijd gestiegen budget, maar lager. Nu, de eerste stap die ik zou adviseren in dit geval om tot een vrij performante opstelling te komen is het schaal van je database. Nu, er wordt heel veel gesproken op wordgames over scalability en zijn heel veel mensen die spreken over varnish en over Redis en over memcache. En ik ga het er ook nog over hebben, maar er is een belangrijke factor dat vaak vergeten geraakt en dat is eigenlijk echt het schaal van je database. Dat is een zeer belangrijke gegeven. In dit geval gaan wij een cluster opzetten van 3 MySQL servers. Gewoon om alle extra database calls te gaan doen. Waarom niet meer? Dat is eigenlijk heel simpel. Wanneer we een WordPress site hebben, in 95% van de gevallen gaat de bezoeker eerst vooral een statische pagina, aangeleefd een homepagina of wat dan ook. En niet iedereen gaat doorklikken op het registratieformuleer. Dus het aantal mensen die een contactfomulier invult of een data invoert in de database gaat sowieso iets lager liggen dan een totale aantal bezoekers. Is 3 genoeg? Hangt dat van je use case. Als je echt een evenement krijgt waar ticketverkoop gebeurt, zet er een paar meer mee. Heb je een evenement waar hier en daar wat database queries moeten gebeuren, maar niet iedereen heeft die noodzaak, kan je perfect met bijvoorbeeld 3 starten. En je kan bijschalen, het is heel eenvoudig om dit uit te breiden met een extra noden. Om je een idee te geven, ik gebruik de absolute basis-setup, absoluut basis-aanbod van DigitalOcean in dit geval. 1 virtuele CPU, 1 gram, daarop zet ik met MySQL server. Dus in totaal zet ik met een kost van 15 dollar in de maand op dit moment. Ik ga nog even terug. Ik heb hier die URL bijgezet. Ik ga niet in detail in gaan op exact hoe die replikatie en alles opgezet wordt van, dan heb ik 3 uur nodig om de volledige taal te geven. Dus dat wordt een beetje moeilijk. Maar ik zou jullie van harte deze link aanbevelen.  Ik tweet straks nog de slides en ik publiceer ze ook nog, want daarin staat echt stap voor stap al eens uitgelegd om dit te kunnen gaan opzetten. Zo hebben we 3 nodes. Wat is een element dat heel vaak vergeten geraakt? Het is eigenlijk zelfs niet geen plug-in, maar je vindt hem op de plug-in repository genaamd HyperDB. Het is een plug-in van Automatic die je voorzorgt dat je vanuit je WordPress kan gaan connecteren met meerdere database-servers tegelijkertijd. Om die connecties te gaan maken tussen WordPress en onze database-servers die we opgezet hebben op DigitalOcean, zijn er een aantal stappen die we moeten nemen. De plug-in download ga je zien als je die inzipt. Daar zitten maar drie files in. Het is geen typische plug-in. Dat komt ook in wp-content.com. Je hebt een db-config file. Daarin moeten we de database-connection strings gaan invoeren. En dan plaatsen we die in de rootmap van onze installatie of waar de wp-config staat als die een niveau over zou staan. Het ziet er dan eigenlijk zo uit als we de wp-config ook gaan editeren. Dit is gewoon het klassieke stuk. Dit kennen we ook. Maar hier staat nu niet meer localhost of de ene server die wel hadden. Maar hier staat dan 01, 02, 03, host, slave1 en slave2. Door die clustering op te gaan zetten, worden de database-connecties nu verdeeld dankzij hyperdb over deze drie database-servers. Wat eigenlijk wel zeggen dat je, waar je bijvoorbeeld eerst misschien 50 of 30 database-connecties de beschikking had op je database, wat een courante waarde is voor de meeste shared hostings, mag je dan nu maar drie gaan doen. Op hetzelfde moment. Dat maakt het al net iets handiger om meer database-interactie ook weer te gaan accumuleren. Vervolgens moeten we de db.php in de wp-content plaatsen zodat WordPress hem ophikt en dat het in gebruik wordt genomen. Voor veiligheidsredenen, alsjeblieft, haal de wijsgrijf vermissies even weg. Kan je met dat commando gaan doen? Nu hebben we in principe onze database gekoverd om iets meer trafiek of iets meer interactie te kunnen gaan onderhouden. Maar dat loopt de problemen met de frontend nog niet op. Want uiteindelijk zitten we nu met een database, een cluster van databases die 90 tot 150 simultaneous connecties aan kan, wat al best aardig is op hetzelfde moment. Maar onze frontend kan nog steeds maar 25 connecties aan.  Kortom gezegd, die database staat daar eigenlijk weinig tot niks te doen. Dus dan kunnen we varnish gaan toevoegen. Varnish, ik heb ook niet een link, maar ik ga er wel iets meer in detail op in. In dit geval zou ik persoonlijk kiezen voor op z'n minste machine van 2 GB, want die varnish gaat wel best wat te verduren krijgen. Dan nog is dit maar een additionele 10 dollar in de maand. Wat op zich weer vrij laag is qua budget. Nu om varnish te gaan opzetten, dat is gewoon eigenlijk een blanko noden die je maakt, blanko link server. Met een paar commando's kan je eigenlijk varnish al heel snel werkend krijgen. Eerst moet je de kie toevoegen aan apt, kan je met dit commando vervolgens, gaan we de repository toevoegen en dan kunnen we gewoon even apt get update en varnish gaan installeren. Op dat moment, als we dan surfen naar tp-adres van onze varnish server, gebeurt er uiteraard nog niks, want varnish is nog niet geconfigureerd om te weten wat hij in het cache moet gaan steken. Nu, in dit geval, varnish komt met een standaard configuratievaal, een zogenaamde VCL, maar dat is echt absoluut basis en in essentie cache quasi alles wat er gewoon binnenkomt. Dus in een WordPress-situatie wil je dat niet, want dan kan je niet meer in de WP admin en dergelijke zaken en dat gaat hele rare dingen doen. Daarom is er VCL specifiek voor WordPress, beschikbaar het is een heel lang adres, maar nogmaals ik tweet ze enzo. En die kan je eigenlijk beter invoeren als de standaard VCL, want deze is specifiek geoptimaaliseerd voor WordPress, dus die houten rekening met de uitzonderingen van de WP admin, plug-in functionaliteiten noem maar op. Dus dit is echt afgestemd op WordPress. In die VCL is dat bestand, dus default.VCL gaan we dan even moeten open doen. En gaan we eigenlijk twee lijnen ook moeten in voor normaan te geven van, kijk waarmee moeten we connecteren. Dat is in dit geval, ik heb die digital oceanode waar ik alles op simuleer, dus de shared hosting zo gedacht, heb ik shared.brecher.com genoemd en uiteraard connecteer we op portachtig, voor het werkverkeer. Op dat moment hebben we eigenlijk in een zeer chimiere basale opzet hebben we eigenlijk de frontend gekoverd staan, we hebben mogelijkheid tot meer back-end connecties ook.  In essentie hebben we nu dit gecreëerd. Totale kost van deze cluster, bovenop onze bestaande hosting, zitten we nu aan 25 dollar, wat op zich een vrij acceptable prijs is. Ik zeg het, je kan ermee schalen, ik zet er nog tweede varnish bij of ik zet er nog 4 MySQL nooit eens bij of ik zet er een tweede web server bij. Dat kan allemaal, maar ik ga eerst eventueel nog ver bekomen met dit. Ik heb de benchmarks opnieuw gerund en om wat iets leesbaar te maken heb ik de output er nu even hier gezet. We hebben dezelfde duizend bezoekers op dezelfde moment, als we net onze server neerhaalden naar de server gestuurd met varnish, die extra toevoeging op de database op dit moment verwerkt die alles in 8.5 seconden en doet die de 144 per seconde. Wat vrij acceptabel is voor een zet van een goede 25, 30 dollar, zeg maar iets of ja. Nu we kunnen daar nog een pak verder in gaan. Zoals ik zei, kan je gaan uitbreiden. Je kan er extra web servers gaan bijplaatsen. Je kan er extra MySQL servers gaan bijplaatsen. Allemaal afhankelijk van jullie budget natuurlijk. Nu, wanneer je extra web servers er gaat bijplaatsen zal je sowieso HAProxy moeten installeren. Dat is eigenlijk op zich ook weer een node die in dit geval dan voor de varnish komt, waar echt alle verkeer binnen komt en die gaat dan, als je bijvoorbeeld drie varnish-nodes hebt, gaat die dan 1 node, 2 node, 3 node, zodat de load overal die machine is heen, onder controle blijft en dat alle zware inkomende trafiek echt op een gunstige manier, op een goede manier verwerkt geraakt. Dan is er nog iets waar ik nog niet echt over sprook heb. Dat is eigenlijk een toevoeg van Redis voor object caching. Waarom zou je dit nog gaan doen? Op dit moment hebben we de frontend gecached. Dan hebben we accommodaties voor meer database interactie, maar we doen geen database caching. Dat wil zeggen, er gaan sowieso in uw site, stel je hebt een, ik zeg maar iets, een WooCommer site waar bepaalde filters worden toegepast, die moeten dan gequeryt worden op de server. Dat zijn queries die door meerdere bezoekers met voldoende regelmaat gaan gemaakt worden om eigenlijk ervoor te zorgen dat ze kunnen gecached worden. In zo'n geval een Redis-node gaan tussensteken.  Ook zo'n basisfomule van 5 dollar, 1 gigabyte RAM komen je al aardig mee, als het geen super grote site is. Als het echt een hele grote site is nemen we niet zwaardere. Het voordeel daarvan is dat Redis gaat eigenlijk de queries die gemaakt zijn en die frequent terugkeren, die gaat die een RAM gaan bijhouden in die waarde. Waardoor die eigenlijk uit RAM meteen kan aanleveren dat de database-servers eigenlijk ook weer ontlast wordt. Die krijgt geen verzoek binnen maar het wordt allemaal rechtstikke uit Redis gehaald. Dit is eigenlijk echt een soort van kuisje die ervoor staat, echt voor alles in zake database. Een enkel trafiek voor queries die uniek zijn of die op geen enkele manier gecached kunnen worden, daarvoor zal de database-server ook weer worden aangesproken. Dus op die manier kan je ook weer een pak extra ja. Request gaan vermijden naar de database-server en ook vermijden dat de database-cluster neergaat. Even kijken. In principe was dat allemaal iets sneller dan verwacht dat we door gegaan. Ja. Natuurlijk. Als je midden op dagen weet dat het database-troop is eigenlijk aanleggen moet je nog eens de mechanisatie plaatsver in de database is in die naamse site. Hoe gebeurt dat? Dat is eigenlijk het is in principe waarom ik ook deze meegeef, omdat ze gaan jullie niet in dit verhaal ook niet alleen tonen van hoe zet je hem op, maar ook hoe zet je de replicatie, want je moet inderdaad een van de nodes gaan definiëren, als een master twee handen als slave dan ook uiteraard de replicatie er tussen in Ordebreng. Er zijn uitzonderingen, er zijn altijd uitzonderingen. Het aantal sites waar het niet mogelijk is kijk, ik kom ze ook tegen maar voor het gros van de sites kan je dit wel doen. Het is wel case by case, inderdaad om te bekijken. Wel, dit is je hebt het op deze slide op cache en apc, dit is eigenlijk gewoon van de formule pagina van de hoster. Dus ze bieden apc aan, ze bieden op cache aan. Ik zou inderdaad apc niet inschakelen wanneer je varnis draaien hebt. Natuurlijk, natuurlijk. Apc, apc zou ik vooral gebruiken voor de niet super zwaar belasten opstellingen.  Eerlijk gezegd wanneer ik het aantal van paar duizend per uur is er eigenlijk geen twijfel mogelijk, dan ga ik sowieso voor varnis gaan omdat varnis net iets meer kan trekken, apc draait in meest gevallen ook weer lokaal op dezelfde server. Waardoor die weer extra belast wordt en varnis staat er voor dus de server wordt echt meer gespaard omdat de database wel weer responsief verblijft waardoor dat alles toch weer net iets flotter gaat. Ik ga apc zeldend tot nooit gebruiken zodra er load komt, ga ik eigenlijk default naar varnis. Alsjeblieft. Die apacitool die je aan het doen houdt ben ik niet alleen op apac die werkt ook in Indonesi en op varnis met de elevers weer mee testen. Wel, wij gebruiken hoofdzakelijk apac dus er zijn nog andere tools die dit doen ook. Ik volgens mij het is te zien wat je wilt doen. In principe, de tool draait gewoon op apache integreert met apache. Dus als een server heeft met apache kan je die wel gebruiken om bijvoorbeeld die trafiek te sturen naar een server die dat niet draait. Maar ik heb het zelf nog zo niet getest dus wij werken eigenlijk hoofdzakelijk met apache dus voor mij is de stap naar A, B is eigenlijk de logische stap. Er zijn andere tools ook. Er is er één die meer universeel is, maar de naam ontgelupt mij spijtig nog even. Ik ga kijken als ik hem kan vinden en laat ik hem hier nog weten. In je test test je uiteindelijk wel in de hoofdpagenaar het heeft niet bij dat het voor de hoofdpagenaar het is de hoofdpagenaar het meest wel statisch. Waarschijnlijk die 2e test die je hoeft waarschijnlijk helemaal niet redaat bij server niet inderdaad. Nee, in principe niet. Ik heb ook nog niet echt een goeie toegevonden om dat echt automatiseerd te gaan testen. Want je weet ook als we in zo'n opstelling naar database queries gaan dan is het vaak omdat er een interactieve ment met de gebruiker op zit. Die gebruiker voor data in en gaat ze publiceren of is aan het filteren in de shop of wat dan ook. Ik heb nog niet echt dergelijke, gemakkelijke tools gevonden om dat echt te gaan automatiseerd te gaan runnen. En ik had ook niet echt 90 mensen in de buurt die even tegelijkertijd op dezelfde fractie van een seconde begin. 