Blog

Hoe test je de schaalbaarheid van jouw applicatie?

Auteur Joep Joep is Quality Engineer bij Trivento en gaat geen uitdaging uit de weg. Hierbij geniet Joep van geautomatiseerd testen, infrastructuur en verbinden.

Is jouw website 24/7 bereikbaar? Super. Het klinkt misschien als de normaalste zaak van de wereld. Maar blijft jouw platform ook staan als er ineens heel veel bezoekers of gebruikers actief zijn? Dat zou bijvoorbeeld voor kunnen komen als er een sale start, er content viral gaat of omdat ineens iedereen een Corona Paspoort aanvraagt. Een piek in de bezoekers heeft gegarandeerd invloed op de reactiesnelheid van je applicatie. Sterker nog, de servers zouden er zomaar uit kunnen vliegen. Dat wil je ten alle tijden voorkomen. Schaalbaarheid is de uitkomst! Een schaalbare applicatie ademt mee met het aantal actieve gebruikers. Maar hoe test je de schaalbaarheid van jouw applicatie? Hoe toekomstvast is de applicatie bij het aansluiten van nieuwe klanten? Je leest het in deze blog.

Snelle reactie van de applicatie is de eis 

Een veel voorkomend gestelde eis is dat een applicatie snel moet reageren. Maar wat is snel? Deze definitie komt terug in het gebruikersgedrag en de daaraan gekoppelde performance-eisen. Dit gedrag kan in de vorm van aantallen per tijdseenheid worden weergegeven. Denk dan aan de vereiste en gewenste responstijden (reactietijden) en het minimale aantal vereiste en gewenste gebruikers.

Echter, er kunnen ook eisen zijn op het gebied van netwerk of  CPU-belasting. Uiteraard reageert het systeem sneller met meer geheugen en CPU, maar tegelijkertijd stijgen ook de kosten. Zeker als het wordt afgenomen in de cloud.

In het verlengde hiervan worden gebruikersscenario’s opgesteld. Je kunt een gebruikersscenario vergelijken met een logisch testscript. In zo’n scenario worden de achtereenvolgende handelingen van een gebruiker vastgelegd. Het doel van een gebruikersscenario is het gebruik van de applicatie te simuleren. Dit vormt de basis van de performance tests.

De gebruikersscenario's moeten zo dicht mogelijk het werkelijke gebruikersgedrag simuleren. Waarbij niet enkel gekeken wordt hoe de  gebruiker door de applicatie navigeert, maar er wordt ook gekeken naar hoe lang een gebruiker een pagina bekijkt. Het bekijken van een pagina is een pauze moment voor de applicatie. Een aantal requests naar de applicatie neemt af en er vinden geen nieuwe aanvragen plaats. Door deze rustpunten kan de applicatie ‘op adem komen’. Wijkt het gebruikersscenario teveel af van de werkelijkheid, dan zal de uitkomst van de performance test een niet realistisch beeld weergeven.

Wanneer komt er rook uit de servers?

Om de verschillende soorten performance testen te visualiserenBinnen Trivento hanteren wij het belastingsmodel o.

Proces metingen Trivento

Het model is opgebouwd rondom het vereiste belastingsniveau. Dit niveau geeft het aantal gelijktijdige gebruikers aan waarvoor het systeem geschikt moet zijn. Daarmee is het veruit mijn favoriete praatplaat. Je maakt heel duidelijk de verschillen inzichtelijk tussen de diverse soorten performance testen. Niet alleen voor de uitvoerenden, maar juist voor de business!

Dit hele proces bestaat uit 4 fasen. Namelijk: 

1 - Performance meting

Het doel van de performance meting is achterhalen hoe het systeem reageert op toenemende gebruikersbelasting. Tijdens de performance meting zal het aantal gesimuleerde gebruikers stapsgewijs opgevoerd worden, totdat het gestelde aantal gebruikers is behaald. Hiermee wordt de applicatie gevalideerd op snelheid van response, schaalbaarheid, stabiliteit en betrouwbaarheid. Zo wordt geborgd dat de applicatie correct functioneert binnen het gestelde gebruikersgedrag.

2 - Loadtest

Met een loadtest achterhaal je hoe het systeem zich gedraagt als er gedurende een lange tijd (tot enkele uren) het vereiste aantal gebruikers gelijktijdig actief zijn. Hiermee zie je of de huidige infrastructuur voldoende is om de applicatie op te laten draaien. Er wordt gecontroleerd of de applicatie last heeft van memory leaks, buffer overflows, time-outs en CPU gebruik.

3 - Stresstest

Bij een stresstest wordt de applicatie langdurig belast. De belasting wordt geleidelijk verhoogd totdat de applicatie uiteindelijk verzadigd raakt en fouten zal genereren. Je komt dan op waarden die ver boven het vereiste belastingniveau gaan. Deze test wijst uit wat de maximale capaciteit van de applicatie en de onderliggende infrastructuur is. Zo wordt bepaald of de applicatie toekomstvast is als het huidige aantal gebruikers groeit.

4 - Piekbelasting

Bij een piekbelasting wordt de applicatie kortdurend (extreem) zwaar belast. Deze test lijkt erg op de stresstest, de prestaties van de applicatie worden geëvalueerd wanneer het aantal gebruikers snel en aanzienlijk worden verhoogd. De belasting is voor korte tijd boven verwachting om eventuele breekpunten boven water te halen. Dit is het punt waarop wordt gezegd: “de rook komt uit de servers”.

Een trage applicatie.. Wat nu? 

De overwegingen die ook gelden bij het kiezen van een testing framework gelden ook bij je keuze voor performance testen. Allereerst is het belangrijk dat de tool het te simuleren gebruikersgedrag en gebruikersscenario volledig ondersteund. De op te stellen testscripts zijn veelal technisch van aard, daarom is het van belang dat de tool goede debugging mogelijkheden biedt. Fouten worden dan snel en adequaat opgespoord en kunnen makkelijk worden opgelost. 

Last but not least moet de tool uitgebreide reporting mogelijkheden bieden. Een grafiek die laat zien dat responstijd welke oploop in de tijd bij een toenemend aantal gebruikers is weinig duidend. Reporting moet inzicht geven waar de bottlenecks van de applicatie liggen. 

 

Response time percentiles over time

 

Binnen Trivento wordt gebruik gemaakt van Gatling voor het uitvoeren van performance testen. De uitgebreide simulatie mogelijkheden en goede reporting zijn hierbij doorslaggevend. 

Performance testen is geen vrijdagmiddag klusje!

Het uitvoeren van een performance test kent vele variabelen. Niet alleen bij het bepalen van het gebruikersgedrag en het gebruikersscenario. Vergeet daarom vooral de volgende vragen omtrent variabelen niet:  

  • Op welk netwerk wordt de test uitgevoerd? 
  • Hoe is de firewall ingesteld?
  • Wat is de capaciteit van de uitvoerende computer?
  • Wat is het huidige verkeer op de applicatie?

Verder is het belangrijk dat de omgeving waarop deze testen worden uitgevoerd gelijk staat aan de productieomgeving (live). Een verkeerd ingesteld variabele zal de test niet doen falen, het geeft wel een vertekend beeld over de performance van de applicatie. Een gemiste of verkeerde variabel heeft grote invloed op het eindresultaat. Daarom bepaal je dit niet even snel op een vrijdagmiddag, je zult er echt  tijd voor moeten reserveren.

De rapportage zal duidelijk inzicht geven in de uitgevoerde tests door details te verstrekken over aantal het requests en de responstijden. Dit maakt trends inzichtelijk en toont mogelijke bottlenecks voor nu of in de toekomst aan. Het rapport is echter niet het belangrijkste hulpmiddel voor het vinden van bottlenecks. De infrastructuur, daar waar de applicatie op draait, moet worden gemonitord op geheugenverbruik en CPU. Evenals de logging van de applicatie waarin eventuele fouten staan welke niet naar boven komen in de test. 

It takes a team.. 

Zowel de voorbereiding als de uitvoering van performance testen is geen one-man-show. Het is echt teamwork om een gedegen performance test op te zetten, uit te voeren én hieruit de juiste conclusies te trekken. Is het resultaat van de performance test dat de applicatie gaat opschalen bij toenemende belasting? Dan is het geslaagd!

Ben je opzoek naar meer?

Bekijk hier een selectie van onze ebooks.

De bouwstenen van een schaalbaar businessmodel

Download nu

Van traditionele organisaties naar digitale winnaars

Download nu

Stappenplan voor digitaal succes

Download nu