Workshop Performance Testing
Afgelopen week heeft InnSpirator Anne de Vries een workshop Performance Testing gegeven aan zijn collega’s van ons Test Gilde. De workshop is bedoeld om de gedachte te leren bepalen wanneer de vraag opkomt of ‘we’ de performance moeten testen. Performance testen kan zoveel betekenen en het is daarom zaak goed uit te vinden wat de organisatie precies nodig heeft. Waar zit de zorg? In het algemeen is de vraag: we hebben iets gebouwd, maar werkt het goed in de praktijk? Of anders: we hebben straks een upgrade of een extensie met betrekking tot functionaliteit – blijft het systeem goed functioneren.
En wat betekent goed functioneren dan?
- Functioneren onder load; grote hoeveelheid gebruik in een min of meer constante aanwezigheid.
- Functioneren onder stress; wanneer het systeem voor een kortere periode een veel hogere load dan gebruikelijk moet ondergaan.
- Een piek (in meer extreme vorm); een korte periode van extreem hoge vraag op het systeem.
- Functioneren over een langere tijdsperiode; dagen, weken, maanden (misschien meer iets voor monitoring van production).
- En over welke performance gaat het?
- De performance voor de eindgebruiker (het systeem opereert met een afdoende snelheid).
- Of de interne performance van het systeem: krijgen de verschillende services en dependencies op tijd antwoord van elkaar.
Het antwoord op de vraag moet afhankelijk van de specifieke zorg, gevonden worden in een laboratorium test, waarin op zo betrouwbaar mogelijke manier de realiteit is nagebouwd en een effectieve test wordt gedraaid voor langere tijd, waaruit betrouwbare conclusies getrokken kunnen worden met betrekking tot productie. Performance testing kan niet op productie en niet op de testomgeving. De test uitkomst moet valide en betrouwbaar zijn. De test- en de labomgeving en de test moeten op een navolgbare wijze de realiteit representeren. En de test moet valide zijn, dat wil zeggen; testen wat getest moest worden, zichtbaar maken waar om gevraagd werd.
Anekdotes:
We hadden een systeem met API calls waarop we moesten performance testen. We extraheren een API call uit de UI (bijvoorbeeld dmv webtools) en kopieerden die call naar jmeter, waarmee we konden opschalen en de call oneindig vaak aan het systeem voorleggen. Is dit een goede test?
Antwoord: het is in ieder geval een goed begin. Je hebt niet de hele UI opgevraagd, maar hebt de performance focus weten te herleiden tot een singuliere API. De vraag is of je die zo eenvoudig kunt opschalen. Wellicht moet de API call met verschillende variaties verzonden worden. Wellicht is er een cache die regelmatig weerkerende API’s van een kant en klaar antwoord voorziet.
Kortom: je moet je systeem heel goed kennen om te weten of je op deze manier te werk kunt gaan.
De website van Tipranks lag plat op een zondagochtend. De performance was kapot door een interne API die een 3rd party API aanriep en het antwoord niet kon verwerken en daardoor kon een centrale service van de website niet met data gevuld worden. Dat is een bug. Verder was er een overload in de nieuwssectie door een incident met het aandeel Tesla. Daardoor was er meer nieuws dan gewoon, maar het veroorzaakte ook het eerste probleem: het aandeel Tesla kreeg een uitzonderlijke status waar de interne API niet op was voorbereid. Het begin van de ellende was een tweet van Elon Musk die qua inhoud niet door de beugel kon met betrekking tot de regels en daardoor wist iedereen de financiële autoriteit de handel in het aandeel zou gaan blokkeren. Zodoende kreeg het aandeel een onverwachte status in de API en extra nieuwsaandacht.
Als je organisatie vraagt om performance testen dan moet je door de volgende fases:
- Welke soort performance is nodig: load, stress, piek, duration.
- Informatie inwinnen: om er achter te komen wat nodig is en hoe eea opgezet moet worden moet je heel veel info inwinnen, die informatie ligt verspreid in de heel organisatie.
- R&D weet hoe het systeem werkt.
- QA weet waar de kwetsbare plekke liggen.
- Support weet wat de meest voorkomende problemen zijn.
- Account management weet wat voor klanten de belangrijkste performance punten zijn.
- Product definition weet vanuit hun perspectief wat de belangrijkste performance punten zijn.
- Wat zijn de risico’s
- Is er een zwaar teruggrijpen op de database?
- Is er een zware front-end?
- Zijn er veel dependencies in de services?
- Is het systeem CPU, of juist geheugen intensief?
- Zijn er mogelijk issues met memory leak of juist met garbage collection?
- Etc.
- Wat ga je testen
- In veel gevallen wil men de performance van ‘het hele systeem’ getest zien. Maar het heeft geen zin om een zware load op een complex systeem los te laten – teveel factoren tegelijk.
- Hoe kan je een focus aanbrengen. Wellicht door heel specifiek services te testen.
- Tegenwoordig wordt de performance van een hele website al door Google getest voor de google rating. Dit is opvraagbaar en in webtools van bijvoorbeeld Chrome terug te vinden – maar dan heb je teveel data voor te weinig requests.
- Hoe ga je het testen
- Als je eenmaal weet welke service, welke API of welk deel van de front-en of back-end de focus moet zijn is de vraag: hoe kan je dit correct bevragen?
- Bouw de juiste configuratie.
- Houd rekening met alle variaties waarin de requests gemaakt kan worden.
- Weet wat een ‘normale’ load is en welke extra load nog acceptabel is – een performance test mag niet ontaarden in een DDoS attack.
- Weet welke caches e.d. aanwezig zijn. Kunnen die uit, kan je die beperken? Je moet ECHTE respons tijden gaan meten en geen razendsnelle grepen uit de cache terwijl je denkt het hele systeem te laten werken.
- Hoe lees je de resultaten?
Een performance test levert heel veel statistieken op. De meeste tools weten dat ook in een mooie grafiek te stoppen.- Tijdlijn
- Percentile grafiek
- Ken het verschil tussen gemiddelde (average) en mediaan (median) – je organisatie zal vragen om de gemiddelde response onder load, maar het meest correcte antwoord is de mediaan en niet het gemiddelde.
- Hoe rapporteer je de resultaten?
- De organisatie wil een groen licht.
- Maar je moet ook in staat zijn om je bevindingen helder en puntig te presenteren.
- De rapportage moet eenvormig zijn, zodat herhaalde performance tests dezelfde rapporten levert en met elkaar vergelijkbaar worden.
Meer weten over Performance Testing? Neem contact op met Marcel Diepenbroek.