In februari 2019 was ik op een Testnet meeting met als thema efficiëntie testen.

Op speelse wijze onderzochten we de bottlenecks in een keten en wat daaraan dan te doen is.
Bijvoorbeeld door het toevoegen van entities en te kijken in hoeverre dit de betrouwbaarheid en efficiëntie van de keten beïnvloedde.

Snelheid en bottlenecks

De browser (persoon 1 in de keten) stuurde verzoeken (wit pingpong balletje) via een buis (netwerk) de keten in. De webserver (persoon 2) bepaalde of hij het verzoek direct kon afhandelen (balletje met vierkantje erop). Zo ja, stuurde hij een oranje pingpong balletje terug naar de browser. Zo niet (ander teken dan vierkantje op balletje) stuurde hij het request via een buis door naar de applicatie (persoon 3).

De applicatie keek of hij het zelf kon afhandelen (uitroepteken op balletje). Bij een ja, stuurde hij een oranje balletje terug naar de webserver, die het terugstuurde naar de browser. Had de applicatie echter een call naar de DB nodig, dus een nee? Dan stuurde hij het request door via een buis naar de DB ( persoon 4). De DB beantwoorde een request met een oranje balletje terug naar de applicatie, webserver en browser.

In een constante stroom gingen requests (balletjes) de keten in. Eerst 1 request (elke 10 seconden) en bij elke volgende meting voerden we het tempo op naar uiteindelijk 1 balletje per seconde.

Het doel? Achterhalen hoe snel het systeem alle 30 requests kon afhandelen en waar de bottlenecks zaten.

Ikzelf vervulde de rol van webserver. Al snel bleek de webserver de bottleneck in de keten daar alle requests hier, zowel heen als terug, doorheen gaan.

Treedt er verbetering op door het toevoegen van een 2e persoon (entity) als webserver? De witte balletjes die vanaf de browser kwamen nam ik voor mijn rekening en iemand anders de oranje balletjes die teruggingen naar de browser. Hiermee ondervingen we dat we tegelijkertijd eenzelfde request oppakten.
Dit leverde nog niet voldoende verbetering op. We voegden nog een load balancer toe zodat we allebei requests konden behandelen.

Dit werkte een stuk efficiënter en de webserver was niet meer de bottleneck, tot dat…

DDOS attack

Als laatste deden we een DDOS attack. Het systeem boven we een emmer vol pingpongballetjes “aan”. Eens kijken hoe snel het hele systeem alle requests verwerkt en of we daadwerkelijk in de stress schoten. En ja, met wat extra aanmoediging van de workshopdocent, kwam die stress wel.

Performance testing, efficientie testen, LST, wat is wat?

Deze meeting had als titel “efficientie testen”. Andere vaak gebruikte benamingen zijn ook wel performance testen, load testen of stress testen. Allemaal testen voor ongeveer hetzelfde. Achterhalen hoe goed je systeem overweg kan met “veel” gebruikers en wat te doen om het systeem hiertoe te optimaliseren.

Load and Stress Testen

Binnen mijn huidige opdracht, bij de Rabobank, voer ik ook zogenaamde Load and Stress Testen uit. Wij erkennen de volgende varianten:

Endurance test

Gedurende 8+uren het systeem belasting aanbieden conform de requirements. Het doel is achterhalen of het systeem de requirements ook langere tijd aan kan, zonder bijv. steeds meer memory te gebruiken en/of een oplopende respons tijd te vertonen.

Breakpoint test

Voer, gedurende langere tijd, stelselmatig de load op tot (ver) boven de requirements. Schaal, zodra de responstijd hierboven komt, terug in load totdat die weer binnen de requirements valt. Zo is de breakpoint load bepaalt.

Scaling test

Een test om te achterhalen of het opschalen in entities, van de applicatie, daadwerkelijk performance verbetering oplevert. Vooral interessant wanneer het breakpoint dichtbij of zelfs onder de requirement ligt. Het werkt overigens alleen als de applicatie de zwakste schakel in de keten is. Zo niet, dan moeten andere delen van de keten aangepast.

Slow backend test

Voer een constante load uit op het systeem. Verhoog vervolgens stelselmatig de responstijd van de backends die het systeem aanroept en meet deze responstijd. Lopen queues vol en gaat uiteindelijk de responstijd harder omhoog dan de responstijd van de vertraagde backends? Presteert het systeem weer normaal zodra de back-end ook zonder vertraging reageert? Onderzoek tevens of jouw systeem al een time-out stuurt naar de “klant” bij een te trage backend. Antwoord een backend, na bijv. 10 seconden, nog niet? Laat de klant dan niet langer in onderzekerheid en meld dat er iets misgaat. Anders gaat de klant zelf op onderzoek uit wat er mis is, terwijl er niks valt te onderzoeken. Het gaat tenslotte bij het systeem mis.

No backend test

Voer een constante load uit op het systeem. Verbreek vervolgens de verbinding naar de backend. Niet alleen de response, maar ook de connectie op TCP niveau. Kijk of het systeem richting de klant (snel) een foutmelding geeft en of het dit langere tijd aan kan. Verbind de backend opnieuw en check of het systeem terugkeert naar normale prestaties.

Een mooi voorbeeld van niet (goed) uitgevoerde “no backend tests” kwam enkele maanden geleden aan het licht in zuid-oost Azië. Googlediensten waren daar ruim 2 minuten niet bereikbaar. Diverse systemen maakten hiervan gebruik en kregen dus problemen. Meerdere systemen kostte het tot 2 dagen tijd, weer volledig operationeel te worden.

Kortom, ook performance testen zijn hard nodig! Met de juiste tools en een goede tester is het nog niet eens zo moeilijk om te doen.