Regelmatig spreek ik testmanagers die vinden dat de kosten voor het neerzetten van een ‘performance testomgeving’ te hoog zijn en (mede) daarom geen performancetesten uitvoeren. Het gevolg daarvan is echter dat we nog steeds veel applicaties met performanceproblemen tegenkomen.
Denk aan eventwebsites die down gaan bij piekbelasting, ticketwebsites die traag worden bij drukte of applicaties die als onderdeel van de kantoorautomatisering ineens niet meer de gewenste snelheid halen. Wat houdt it-afdelingen dan ook tegen om een applicatie te testen voordat deze live gaat? In deze blog zet ik de drie redenen op een rij die ik het meeste horen.
Geen zin
Reden 1: ´Performancetesten in een testomgeving heeft geen zin´. In de ideale situatie is een performance testomgeving beschikbaar met exact dezelfde capaciteit en architectuur als de productieomgeving. Maar een ‘productie-like’ testomgeving zien we in onze praktijk zelden. Testomgevingen kosten geld en worden daarom zo eenvoudig mogelijk uitgerust – met als doel de applicatie functioneel te laten werken.
Maar heeft het daarom geen zin om een performancetest uit te voeren in de testfase van applicatieontwikkeling? Zeker wel! De snelheid van een applicatie is bijvoorbeeld niet afhankelijk van het aantal servers dat naast elkaar gebruikt wordt. Responstijden kunnen daarom goed gemeten worden op een enkelvoudige configuratie. Zelfs het gebruik van trage servers in een testomgeving heeft een voordeel: als de applicatie daarop voldoende snel presteert, kan de garantie worden afgegeven dat de applicatie nog sneller zal zijn in de productieomgeving met snellere hardware. Verder leveren de grenzen die in een testomgeving ontdekt worden, nuttige kennis op voor de inrichting van de productieomgeving. Bijvoorbeeld voor de configuratie rond connectiepooling, en de wijze waarop de capaciteit van een applicatie zich laat schalen.
Het is dus juist zinvol om te performancetesten op een ‘minderwaardige’ testomgeving. Mijn advies: maak sowieso gebruik van een testomgeving, ongeacht of deze ‘productie-like’ is.
Testdata
Reden 2: ´Er is onvoldoende testdata´. Testomgevingen bevatten vaak niet meer dan maar een paar of tientallen testgevallen. De vullingsgraad van de database is dan niet representatief voor de situatie in productie. Heeft performancetesten in zo’n lege omgeving dan wel zin? Jazeker!
De meest complexe performanceproblemen worden veroorzaakt doordat applicaties inefficiënt omgaan met hun data. Deze categorie problemen is juist in een testomgeving met weinig testdata goed te detecteren en te analyseren. Los ze zo vroeg mogelijk in het ontwikkelproces op, voordat er meer functionaliteit van afhankelijk wordt. Is data vulling dan helemaal niet nodig voor performancetesten? Zeker wel, maar het soort performanceproblemen dat gevoelig is voor data volumes is eenvoudig te detecteren en op te lossen. Bij voorkeur doen we dat in de testfase, maar monitoren en oplossen in productie omgeving kan een verantwoorde keuze zijn.
Mijn advies: performancetesten worden bij voorkeur uitgevoerd op een realistisch gevulde database. Maar voor het vinden van de meest ernstige performance problemen is de aanwezigheid van grote aantallen database regels niet van belang. Voer dus altijd een performancetest uit voor live-gang.
Veel tijd
Reden 3: ´Performancetesten kost te veel tijd´. Dit is eigenlijk nooit een goed argument. De voorbereidingstijd die nodig is om een goede performancetest te maken kan fors zijn, maar deze is goed in de hand te houden. Het is vooral de (on)ervarenheid van de persoon die de performancetesten maakt, dus de leercurve, die de voorbereidingstijd laat toenemen. Ook de dekking en complexiteit van de test die men denkt te moeten realiseren, kan voor lange trajecten zorgen. Tot slot vindt het maken van een performancetest vaak plaats naast alle reeds lopende werkzaamheden, waardoor de test geen focus heeft en alleen al daardoor langer duurt dan nodig.
Mijn advies is: laat een performancetest opzetten door een ervaren performancetester en draag deze dan over aan de eigen mensen. Denk vooraf na over de risico’s die voor uw applicatie(s) gelden en laat dit meewegen in de samenstelling van de performancetesten. Laat u adviseren en wees flexibel in de afwegingen die nodig zijn om een goede set met uitgangspunten op een rij te krijgen voor de performancetesten.
Keuze
Grote problemen zijn de uitvergroting van kleine problemen. Kleine problemen kunnen met performancetesten gevonden worden in een beperkt geschaalde testomgeving met maar weinig data. Ook applicatiegedrag met grote datasets kan eenvoudig worden nagebootst in een testomgeving. Verder is de keuze natuurlijk aan u: halen we 90 procent van de performanceproblemen uit de applicatie en blijft de onverwachte 10 procent zitten voor productie? Of zet u de volle 100 procent risico’s door naar productie? Het is uiteindelijk een afweging tussen belangen, risico’s en kosten.
De klacht dat de kosten voor ‘het neerzetten van een performance testomgeving te hoog is’ komt me niet onbekend voor en performance klachten als gevolg van deze zuinigheid ook niet. Ik verwijs daarom graag naar de Theory of Constraints (ToC) aangaande efficiëntie versus effectiviteit, er zijn tenslotte verschillende performancetesten waardoor je uiteindelijk niet alles hoeft te testen om te weten waar de bottleneck zit.
Bedrijfskundig weten waar de bottleneck zit maakt het capaciteitsmanagement een stuk eenvoudiger en oplossing voor veel van de performance problemen zit dan ook in de magie van QoS. En performance testen kunnen (op basis van ToC) veel geld besparen want waarom zou je veel resources gunnen aan een proces dat weinig waarde toevoegt aan de keten?
De goede set met uitgangspunten voor een performance test (what if?) gaat in de eerste instantie om de business case, discipline van BPM wordt nog niet (op)gevoed met gegevens over de bezettingsgraad terwijl hier tijdens testen inderdaad meer aandacht aan gegeven moet worden. Tenslotte ontstaan problemen in de productie vaak door slecht capaciteitsmanagement, de race voor resources is in virtuele omgevingen alleen maar groter geworden.