Checklist: voorbereiding op drukke momenten voor je webapp of webshop

Hoe verleidelijk het ook is, ga niet pas na een brand blussen. In dit geval: nadat je webapp of webshop trager is geworden tijdens een piekmoment, of in het ergste geval niet meer bereikbaar is geworden. Een gedegen voorbereiding is meer dan het halve werk: maak van performance en snelheid het hele jaar door een prioriteit.

Performance continu meenemen betekent bijvoorbeeld:

• afbeeldingen altijd geoptimaliseerd voor web uploaden;
• je web vitals in de gaten te houden en acties ondernemen;
• weten of je laatste code change een positieve of negatieve performance impact heeft (en actie ondernemen als dat een negatieve impact heeft).

Zodra je je webshop of webapp een geruime tijd up-and-running is, heb je voldoende data om bestaande piekmomenten te analyseren. Wat betekent een piekmoment voor jouw platform? Om hoeveel extra bezoekers en requests gaat het dan ten opzichte van dag-, week- of maandgemiddelden? En op welke momenten ervaar jij of ervaren je bezoekers een tragere shop of app? Met deze cijfers en inzichten creëer je een beter beeld van het piekverkeer dat je kunt verwachten.

Heb je de mogelijkheid om een piekmoment uit te spreiden? Bijvoorbeeld door niet alle nieuwe gebruikers op precies dezelfde dag en precies dezelfde tijd een mail met hun inloggevens te sturen? Spreiden ervan zorgt voor een langere periode van meer verkeer en minder kans op piekverkeer. Zelfs als het gaat om een campagne die op één dag start, helpt het al om een e-mailing te verspreiden over 5 of 20 minuten waar mogelijk.

Met de analysevan bestaand piekverkeer kun je vervolgens kijken waar de load op resources vandaan komt. Vraagt je shop of app bijvoorbeeld veel data in veel requests van je database op? Optimaliseer daar je database requests en database voor (zie ook check 7).

Wees er wel van bewust dat de load op resources niet één-op-één stijgt als het aantal bezoekers of gebruikers stijgt. 4 keer meer resources inzetten betekent niet automatisch dat je webshop of webapp dan ook 4 keer meer bezoekers aan kan. Een applicatie (of query-tijden) kan zich anders gedragen bij grotere hoeveelheden bezoekers.

Met performance testen meet en evalueer je hoe je webshop of webapp werkt onder hoge druk. Specifiek zijn er load testen (hoeveel gebruikers kan je platform aan) en stress testen (wat is het maximale dat je platform aan kan). Dit soort type testen staan er niet om bekend dat ze snel uitvoerbaar en goedkoop zijn. Ze leveren echter wel een schat aan informatie en analyse op of een (grote) wijziging in je code positief of negatief voor je performance is. Een eerste performance test kan als standaard dienen, waarna je idealiter bij elke (grote) change opnieuw een test uitvoert.

Elke nieuwe request naar de webserver, en dan met name naar je database, levert belasting voor de webserver op. Front-end caching van pagina’s, waarbij pagina’s tijdelijk statisch worden, helpt deze belasting te verlagen. Gebruik bijvoorbeeld een caching module van je coding framework of een caching plugin in je CMS. Weet dat verschillende typen cache ook verschillende aanroeptijden kenen: disk cache is over het algemeen trager dan het vluchtigere en snellere ram cache.

De volgende stap in caching is het inzetten van caching software op je server, back-end caching. Dat kan in de vorm van Varnish Cache, Redis Cache of Elastic search. Door caching in de front- en back-end toe te voegen, kun je de belasting van je webshop of webapp op de server verder verlagen.

Een database die optimaal presteert, krijgt niet te veel requests van je webshop of webapp. En als er requests zijn, dan precies voor die informatie die nodig is.

Ook kan de gebruikte logica voor de database zorgen voor onnodige load op de database. Bijvoorbeeld als je code een alter table request uitvoert, is de database op dat moment gelockt. Een kleine lock per keer, van een paar tienden milliseconden, is geen ramp voor de performance. Gebeurt dat echter bij elke gebruiker en heb je het over duizenden gebruikers tegelijk, dan kan dat de performance nekken. Optimaliseer en tune je database voor het piekverkeer.

Wat gebeurt er als een specifieke (micro-)service uitvalt door piekverkeer? Doet de rest van je webapp of webshop het dan nog wel?

Verwerk fault tolerance in je code: dit complexere design ondervangt elke uitval van een component. Als een service onverwachts uitvalt, welke andere service kan dat dan opvangen? Of als alle servers uitvallen, heb je dan redundantie door middel van servers in een ander datacentrum?

Alle software en framework-versies raken op een moment verouderd. Nieuwere versies leveren je niet alleen nieuwe features op die je kunt gebruiken, ook zijn ze vaak efficiënter. Daardoor wordt de performance beter en de toepassing sneller. Als voorbeeld: MySQL 8.0 (de huidige versie in 2022, released in 2018) is flink sneller dan MySQL 5.7 (release 2015). Zorg dat je gebruikte software up-to-date is en dat ook je servers over een update van het OS beschikken.

Wat mag je van engineers verwachten om in te spelen op verwacht piekverkeer of campagnes die je aangeeft?

Het belangrijkste: zorg dat we op de hoogte zijn van de (grote) campagne die je gaat draaien of het piekverkeer dat je verwacht door het aansluiten van veel nieuwe gebruikers.

• We kunnen je dan helpen met caching aan server zijde, zoals het inzetten van Varnish of Redis. Wij installeren het voor je, waarna je zelf aan de slag kunt gaan met in gebruik nemen;
• We checken je bestaande resources en servers om te kijken welke tweaking en tuning we kunnen inzetten, zoals serverlimieten of RAM geheugen, met waar nodig uitbreiding van resources;
• We ondersteunen bij load testing;
• En we helpen bij advies voor en een analyse van je huidige omgeving.

Toets je plannen met True engineers om een Truely Good Launch van je campagne of piekmoment te maken!