Performantie van je website

    Roald Lenaerts
    by Roald Lenaerts
Pagina snelheid of performantieproblemen Level27

EEN SNELLE WEBSITE IS ENORM BELANGRIJK!

In de tiende aflevering van Hotline27 vertelt Roald je meer over de performantie van je website. Een interessant en actueel onderwerp. Voor veel handelaars is hun webshop in tijden van corona namelijk de enige bron van inkomst, dus het is erg belangrijk dat die snel is en up blijft. De volledige podcast kan je hier beluisteren: 

 

 

 

EEN TRAGE WEBSITE, WAT DOE IK ERAAN?

Er bestaan verschillende redenen waarom een website traag kan zijn. De meest voor de hand liggende oorzaak van een trage website is te weinig resources. Het heeft geen nut om je applicatie te optimaliseren als je achterliggende infrastructuur deze applicatie niet kan dragen. 

Een andere mogelijke oorzaak van een trage website is bijvoorbeeld een trage SQL-query. Deze query wordt vaak uitgevoerd en zorgt ervoor dat het systeem instabiel wordt. Je kan dit heel simpel oplossen door snellere servers te kopen met meer opslag of memory. Maar dat betekent natuurlijk dat je servers ook duurder worden waardoor dit voor een kleinere applicatie niet de ideale oplossing is.

Het is hier belangrijk om niet meteen de schuld van je performantie bij de applicatie zelf te leggen, maar als hostingpartner nemen wij onze verantwoordelijkheid om ook daar op zoek te gaan naar achterliggende problemen, zoals te weinig memory, te weinig cpu of te weinig disk-IOPSen (input/output operaties). Wanneer deze drie issues samenkomen is het moeilijk uit te zoeken waar het probleem net vandaan komt en in dat geval is het nuttig om statistieken te verzamelen: waarvoor worden de resources van je server gebruikt? 

OP ZOEK NAAR DE OORZAAK VAN EEN TRAGE WEBSITE

Maar hoe begin je aan die statistieken? Daarvoor bestaan een aantal hulpmiddelen en werkwijzes.

Prometheus-exporter

Met Prometheus-exporter kan je pure performantiestatistieken verzamelen zoals CPU, memory en queries. Bijkomend kan je data met betrekking tot queries opvragen: hoeveel queries lopen er, hoe lang duren die, ... Deze data kan je vervolgens in Grafana weergeven in de vorm van een dashboard. Op die manier zie je in het dashboard bijvoorbeeld dat er op een bepaald moment een piek heeft plaatsgevonden en de achterliggende oorzaak duidelijk wordt aangegeven.

Ervaring & tools

Hoe hou je het overzicht wat de ideale setup is voor elke omgeving is wanneer je veel servers beheert? Wel, dat is in eerste instantie een kwestie van ervaring. Daarnaast is het belangrijk om de gevolgen op je applicatie te onderzoeken, dit wanneer er aanpassingen in je setup gebeurd zijn. 

Maar als je door de bomen het bos niet meer ziet, bestaan er tools om je te helpen met deze setup. Een voorbeeld hiervan is MySQL Optimizer. MySQL Optimizer is een scriptje dat je vertelt welke aanpassingen je kan doen om je setup te verbeteren. Enorm handig toch? 

Een andere manier van werken is slow logging. Dit is een configuratie die je makkelijk kan instellen aangezien dit standaard in MySQL of PHP zit ingebouwd. Met slow logging kan je onderzoeken welke PHP traces of MySQL queries precies traag werken op je applicatie. Met deze manier kan je gericht de trage processen eruit filteren en gaan optimaliseren. Helaas kan het aantal logfiles zeer hoog oplopen. Het analyseren van de logs kan je op een goed spoor zetten, maar brengt je niet helemaal tot de oorzaak van het probleem.

NewRelic

NewRelic kan een antwoord bieden op wat we missen via slow logging. NewRelic is een software die een uitgebreide analyse maakt van wat er op je server gebeurt en dit mooi in een dashboard toont. Zo zie je bijvoorbeeld dat een gebruiker een transactie uitvoert op de homepagina van een website en 20 seconden heeft moeten wachten. NewRelic laat je dan zien welke queries dit hieraan gelinkt zijn, of toont aan dat er bijvoorbeeld vertraging was door een externe API call, enzovoort. Zo krijg je meteen inzicht in de oorzaak van je slechte performantie.

WANNEER ZIT HET FOUT IN DE APPLICATIE?

Hoe weet je dat er iets fout zit en dat dit tot een effect op de performantie van je website kan leiden? Een performantieprobleem kan aanvankelijk al sterk aanwezig zijn, maar ook heel geleidelijk aan groter worden. Net dan is het heel interessant om loadstatistieken bij te houden zodat je veranderingen kan opvolgen. Zo kan je zien dat de server load maakt terwijl er nog geen gevolg voor je applicatie is en kan je optimaliseren om problemen te vermijden.

Loadtesten

Om te voorkomen dat veel load effectief tot problemen in je performantie leidt, zijn loadtesten (of stresstesten) erg nuttig. Als de loadtest uitgewerkt is kan je die in principe voor elke aanpassing uitvoeren om te kijken of de aanpassing je performantie heeft aangetast. Je kan dit proces van loadtesten vervolgens ook automatiseren. 

De meest eenvoudige software voor loadtesten is AB (Apache Benchmark) die je uitvoert vanuit een lokale pc. Een ander voorbeeld is loader.io die een stapje verder gaat: er worden een aantal systemen in AWS opgezet van waaruit requests worden afgevuurd om toch iets meer in te spelen op de werkelijkheid. Nog een stap verder is BlazeMeter, waarmee je volledige flows kan repliceren: het inloggen van een gebruiker, het bestellen van een item, naar het winkelmandje gaan tot en met het afrekenen. De uitwerking ervan is natuurlijk meer werk, maar het is wel de meest optimale manier om de applicatie testen. 

DE OPLOSSING: CACHING?

Als je het probleem niet structureel kan oplossen zal caching vaak een oplossing zijn. Cachen kan je enerzijds zien als het verdoezelen van het probleem. Maar het is wel een logische stap als je bijvoorbeeld een query wil uitvoeren die veel resources nodig heeft, want caching zorgt dat er terug wat resources vrijkomen.

Cachen kan op verschillende niveaus maar de meeste performante manier is in het memory. Dit op twee verschillende manieren: object caching en page caching. 

Voorbeelden van object caching zijn Memcached of Redis, beide een ‘key value store’ waarin je het resultaat van je database queries opslaat zodat de volgende gebruiker dezelfde query niet moet uitvoeren maar het resultaat rechtstreeks uit het memory gehaald kan worden. Dit is vrij eenvoudig om te integreren omdat de Memcached of Redis integraties vaak al verwerkt zitten in de CMS van je website.

Bij page caching worden volledige pagina’s in het memory geplaatst. De meest bekende service hiervoor is Varnish. Hoe werkt Varnish eigenlijk? Elke gebruiker navigeert naar een bepaalde pagina en Varnish onderzoekt vervolgens om welke url het gaat, welke cookies worden meegestuurd, welke headers erin zitten,... De pagina wordt vervolgens met deze parameters opgeslagen. Als er dan een nieuwe gebruiker met dezelfde parameters op de website komt, wordt de pagina uit het memory getoond. Dit is de meest performante manier van werken, maar helaas ook de meest complexe om te integreren. 

HOE KAN IK NOG MEER RESOURCES BESPAREN?

Als je de logs van je website onderzoekt merk je dat er ook veel ongewenste bots op je website terecht komen die natuurlijk ook resources gebruiken. Daarom is het belangrijk en nuttig om je website te beschermen via een web application firewall zodat dit soort bots volledig geblokkeerd worden van de server. 

CONCLUSIE VAN PERFOMANTIE PROBLEMEN

Steek niet zomaar resources bij, onderzoek waar je probleem zit. Je kan een probleem oplossen op de snelle manier of op de goede manier. Kortom, pak de problemen aan waar ze zich voordoen!

 

Contactgegevens

+32 (0)89 449130 Via Media 4
3500 Hasselt, België

BTW: BE0890 439 412
IBAN: BE73 6451 0290 9860
BIC: JVBABE22

Heb je na het lezen van deze blog vragen over performantie of hosting in het algemeen?

Vragen of opmerkingen?

Laat het ons zeker weten via onze chatbox!
We helpen je graag verder.

Deel deze blog via