Wanneer ontwikkelpartijen een applicatie hebben ontwikkeld moeten ze verschillende kwaliteitsaspecten nalopen. Hiervoor gebruiken ze vaak een eenvoudige checklist. Functionele kwaliteit? Check. Compliance? Check. Performance? Check!
Dan is het de beurt aan de beherende partij: zij stellen de benodigde hardware samen volgens de specificaties van de ontwikkelaars. Hierop wordt het nieuwe softwarepakket geïnstalleerd. Ook hierbij worden er nog een aantal functionele testen gedaan en dan kan de applicatie in productie.
Niet zo lang en gelukkig…
In eerste instantie functioneert de nieuwe applicatie naar behoren. Maar na een aantal weken komen toch klachten: de applicatie is toch niet zo snel als verwacht. Wanneer de traagheid niet wordt opgelost, kan het van kwaad tot erger gaan totdat de applicatie onwerkbaar is. Het herstarten van de servers biedt een tijdelijke oplossing, maar uiteindelijk keren de problemen terug. Het opschonen van data is ook een techniek die de applicatie weer tijdelijk nieuw leven in blaast. Door beide technieken regelmatig toe te passen lijkt de applicatie stabiel. Dit is echter pleisters plakken in plaats van de wonden helen. Het beheer van de applicatie wordt hiermee een dagelijkse zorg.
Bij een slecht presterende applicatie zien we vaak dat betrokken partijen bij de schuldvraag naar elkaar wijzen. Externe consultants worden ingevlogen om onderzoek naar de bottleneck te doen, maar de verbetermogelijkheden zijn beperkt nu de applicatie al live is. Een snelle oplossing lijkt buiten handbereik en de onderlinge verhoudingen tussen de betrokken partijen wordt er vaak niet beter op.
Problemen voorkomen
Dit scenario komen we in de praktijk nog veel tegen, maar is niet nodig. Voordat een applicatie wordt gelanceerd kan met een performancetest in de testomgeving worden nagegaan hoe deze onder belasting zal presteren. Het samenstellen en uitvoeren van een goede performancetest is echter niet eenvoudig. De test moet van hoge kwaliteit zijn om écht inzicht te bieden in de performance, waarnaar er een verbeterslag kan worden gemaakt.
Maar hoe ziet een goede performancetest er dan uit? De test moet een juiste samenstelling van scenario’s hebben, waarmee specifieke risico’s op performance worden getoetst. Een website die beschikbaar moet zijn tijdens noodsituaties, moet bijvoorbeeld veel verkeer tegelijkertijd aankunnen. Een applicatie die maar een klein aantal gebruikers heeft, moet vooral snel zijn en daarbij is de piekbelasting van ondergeschikt belang. Andere vragen kunnen zijn: herstelt een applicatie zelfstandig na overbelasting? Of wat gebeurt er als de infrastructuur tijdelijk verbroken wordt? Iedere applicatie heeft een ander type performance test (of meerdere typen) nodig om de gewenste scenario’s te testen.
De kwaliteit van applicaties valideren met behulp van performance testen voor livegang is dus belangrijk maar vereist enige kennis en uiteraard is de juiste tooling nodig. Uit de testen komt noodzakelijke kennis waarmee de juiste configuratie en schaling van een applicatie in de productieomgeving bepaald kan worden. Het is dus van belang om met een leverancier goed af te stemmen welke snelheid gebruikers mogen verwachten en om dit door te vertalen naar de juiste testen. Hiermee voorkom je dat een applicatie bij livegang toch niet naar behoeven functioneert en behoud je tevreden gebruikers. Ready? Test, go!
Leuk artikel. Aanvulling op basis van eigen ervaringen: zorgen dat je test met een representatieve infrastructuur.
Lokaal bij de ontwikkelaars een client-server applicatie testen geeft qua performance een heel ander beeld dan wanneer de server in bijv. Amsterdam staat en de gebruiker in Bangalore zit.
Hier heb ik in de loop der jaren meerdere applicaties op zien struikelen.
Ik kan een paar e-mails gemist hebben maar Marcel lijkt zich te vergissen aangaande de specificaties die door de ontwikkelaars gegeven worden voor de samenstelling van de hardware. Simpele gegevens zoals de I/O karakteristiek, het netwerk- en geheugengebruik of een processorbelasting ontbreken veelal als een applicatie overgedragen wordt aan beheer. Want de meeste ontwikkelaars leven in een droomwereld van serverless oplossingen met een oneindige schaalbaarheid in resources. Dat er ondertussen een strijd om resources in de cloud geleverd wordt doordat delen van de infrastructuur overbelast zijn wordt niet goed begrepen.
De vraag is of Ymor een ‘root cause analyses’ kan doen door de knelpunten te vinden in de infrastructuur om zoals de Theory of Contraints stelt deze te kunnen oplossen. Want het testen van een applicatie response zonder inzicht in de belasting van de individuele componenten van de infrastructuur is nogal zinloos. Oja, er zijn natuurkundige beperkingen in de infrastructuur die als de muur zijn waarop applicaties crashen. En één van de bottlenecks in de infrastructuur is de maximale doorvoer van de bus. Meten is weten, maar kennis is oplossen want Quality of Servie is als een toeritdosering bij de Coentunnel.
Ik heb meer dan 100 onderzoeken gedaan naar performance problemen en weet daarom dat een voorspelbaarheid van de response om de som van de prestatie van alle individuele componenten in een keten gaat. De snelle oplossingen die ik had waren eenvoudig en goedkoop want een batch-verwerking tijdens de spits is niet slim. De optimale verdeling van resources vraagt enige planning maar is niet zo moeilijk omdat de meeste bedrijfsprocessen voorspelbaar zijn.
Bent u bekend met de oplossingen van Smartbear?
Het maken van een realistische load-test met tools als Loadrunner is geen simpele opgave. Zoals PaVaKe opmerkt is de end-to-end response time iets heel anders dan het meten op dezelfde lokatie als de server. En zoals Ewout opmerkt bestaan er ontwikkelaars die volledig losgezongen zijn van de hardware waarop hun software draait en geen enkele rekening houden met mogelijke optimalisaties (bijv. indexering van data, caching).
Bij een performance test gaat het erom om te zien of een zekere piekbelasting haalbaar is. Daarvoor moet een realistische test worden ontworpen en worden uitgevoerd (idealiter in de produktie omgeving en anders in een omgeving die produktie benaderd in termen van CPU en memory (capaciteit). Een realistische test dient zoveel mogelijk het gebruikersgedrag te simuleren en de diverse onderdelen van een enkele transactie qua tijdsduur te benaderen. Ook de data waarmee wordt gewerkt moeten datareeksen zijn in de zin dat niet binnen alle transacties dezelfde data wordt gebruikt. Anders staat die data al snel in een applicatie of database cache en zijn de responsetijden niet meer reeel.
Vaak hebben performancetesters geen enkel idee hoeveel concurrent users te verwachten zijn voor een zekere applicatie.
Eric Man Wong heeft in 2004 een leuk artikel geschreven wat eigenlijk iedere loadtester zou moeten lezen:
“Method for Estimating the Number of Concurrent Users” . Het is nog te vinden als eerste artikel in dit online magazine:
http://www.qualityweek.com/News/QTN-Online/qtnoct04.html