Introductie Performancetesten SYSQA B.V. Almere Datum : 19-12-2014 Status : Definitief
Organisatie: SYSQA B.V. Pagina 2 van 12 1 Inleiding SYSQA is een onafhankelijke organisatie, gespecialiseerd in het toepassen van kwaliteitsmanagement in ICT. Binnen kwaliteitsmanagement is er aandacht voor alle eigenschappen die de kwaliteit voor de eindgebruiker en de opdrachtgever bepalen. Deze eigenschappen betreffen bijvoorbeeld de kwaliteitsattributen performance of security van een systeem. Deze introductie gaat dieper in op performance testen. Performance testen is een specialistisch vakgebied met een veelal technische inslag en met zijn eigen vocabulaire. Deze introductie maakt de lezer bekend met de basisbegrippen en de belangrijkste aspecten van performance testen. Voor een dieper begrip van en enige praktische oefening met het performance testen is de cursus Performance- & Securitytesten beschikbaar.
Organisatie: SYSQA B.V. Pagina 3 van 12 Inhoudsopgave 1 Inleiding...2 2 Wat is performance testen?...4 2.1 Definitie performance... 4 2.2 Waarom performance testen... 4 2.3 Uitgangspunten performance testen... 5 2.4 Soorten performancetesten... 5 2.4.1 Loadtest... 5 2.4.2 Stresstest... 6 2.4.3 Peaktest... 6 3 Aanpak performance test...8 3.1 Test voorbereiding... 8 3.1.1 Omgeving en infrastructuur... 8 3.1.2 Gedrag... 8 3.2 Tooling... 8 3.2.1 Load tooling... 8 3.2.2 Parametriseren... 9 3.2.3 Controleren van het resultaat... 9 3.2.4 Testen op kleine schaal... 9 3.2.5 Monitoring tooling... 9 4 Bronvermelding...10 Bijlage 1: Vragen aanpak performance testen...11
Organisatie: SYSQA B.V. Pagina 4 van 12 2 Wat is performance testen? In dit hoofdstuk worden verschillende definities en begrippen in hoofdlijnen besproken. Ten eerste gaan we in op wat performance testen is. Performance testen is een testvorm waarbij de prestaties (performance) van een systeem worden getest. Voordat we hierop ingaan wordt het begrip performance uitgelegd. 2.1 Definitie performance Performance wordt door ISO 25010 gedefinieerd als: De prestaties in verhouding tot de hoeveelheid middelen gebruikt onder genoemde condities. Daarnaast geeft TMap Next een definitie toegespitst op informatiesystemen: Performance is de snelheid waarmee het informatiesysteem interactievebatchtransacties afhandelt. en Performancetesten is feitelijk een verzamelnaam voor verschillende testtypes, te weten loadtesten, stresstesten, peaktesten, endurancetesten en benchmarking. Binnen SYSQA zijn de meest voorkomende soorten performancetesten de load-, stress- en peaktesten. Endurancetesten en benchmarking kunnen onder loadtesten geschaard worden. De bovenstaande soorten performancetesten worden in deze introductie behandeld. 2.2 Waarom performance testen Hoewel nu is vastgesteld wat performancetesten precies is, is nog niet de vraag beantwoord waarom er eigenlijk op performance getest wordt. De mate van performance speelt bij veel verschillende systemen een belangrijke rol bij het succes van dit systeem. Responstijden van webapplicaties spelen bijvoorbeeld een grote rol bij het klikgedrag van gebruikers. Slechte responstijden zijn voor veel gebruikers een reden om websites vroegtijdig te verlaten of geheel te vermijden. Bedrijven verliezen als gevolg hiervan klanten en hun bijbehorende omzet. Testen uitgevoerd door Amazon.com laten zien dat elke 100 milliseconde extra responstijd op Amazon.com leidt tot een daling in de omzet van 1%. 1 Bedrijven zijn er daarom bij gebaat te weten dat de performance van hun systemen op een voor de gebruikers acceptabel niveau is. Dit is zowel relevant bij acceptatiecriteria voor nieuwe systemen, als bij huidige systemen die al enige tijd in gebruik zijn en mogelijk niet meer voldoen aan de veranderende prestatie-eisen. De performance is ook van groot belang bij de communicatiesystemen van veiligheidsdiensten. De gebruikers van deze systemen moeten er op kunnen vertrouwen dat bij grote rampen, waarbij veel hulpverleners actief zijn op het communicatiesysteem, dit systeem goed blijft functioneren. Door middel van performance testen is bijvoorbeeld het antwoord te verkrijgen op de vraag welke hoeveelheid dataverkeer het door hulpdiensten gebruikte communicatiesysteem C2000 kan verwerken. 1 (2009) Latency is everywhere and it costs you sales how to crush it. Retrieved 12 december 2014 from http://highscalability.com/latency-everywhere-and-it-costs-you-sales-how-crush-it
Organisatie: SYSQA B.V. Pagina 5 van 12 2.3 Uitgangspunten performance testen Om de performancetest vorm te geven moet er een evenwicht gevonden worden tussen representativiteit, risicovolle componenten en de beschikbare hoeveelheid tijd en geld. Onder representativiteit wordt de manier verstaan waarop het systeem zoveel mogelijk vergelijkbaar met de huidige of toekomstige productiesituatie belast kan worden. Dit kan variëren van weinig data met veel gebruikers en veel data met weinig gebruikers, tot veel data en veel gebruikers. Hiervoor moet inzicht worden verkregen in de realistische gebruikersaantallen, databasevulling, hoeveelheid transactie, etc. Bij risicovolle componenten kan de vraag worden gesteld welke transacties en systeemcomponenten als gevolg van requirements, softwarefouten of hardware beperkingen het meest kwetsbaar zijn bij een toenemende belasting. Bij tijd en geld draait het om de vraag binnen welk budget en welke doorlooptijd een oordeel gegeven kan worden over de performance. Het zo representatief mogelijk maken van een test kan veel tijd en geld kosten. Het focussen op de meest risicovolle componenten kan echter resulteren in een nietrepresentatieve situatie omdat bepaalde transacties met een hoog volume, maar lage prioriteit, buiten de performancetest worden gehouden. Het is dus belangrijk om aandacht te schenken aan het maken van een afweging tussen deze uitgangspunten en te bepalen welk van de punten zwaarder wegen bij de uit te voeren performancetest. 2.4 Soorten performancetesten De verschillende soorten performancetesten onderscheiden zich op het gebied van de verwachtingen van de prestaties van het testobject. 2.4.1 Loadtest Een loadtest stelt de systeemomgeving bloot aan een representatieve belasting. Deze belasting wordt trapsgewijs opgebouwd om te zien hoe de responsetijden zich ontwikkelen, zie Figuur 1. Figuur 1: Opbouw loadtest Het is belangrijk om de gegevens trapsgewijs op te bouwen, aangezien het meestal niet representatief is dat een grote groep gebruikers tegelijkertijd inloggen op het systeem (indien dit wel het geval is, moet er een peaktest uitgevoerd worden, zie 2.4.3). Door middel van een loadtest wordt dus de performance van het systeem op het gebied van responstijden, doorvoer et cetera getest onder een voor productie realistische belasting. Naast de standaard loadtesten kunnen er ook endurancetesten of benchmarks uitgevoerd worden. Endurancetesten is het langdurig testen van het systeem onder een representatieve belasting, om zo effecten te vinden die pas na langere tijd zichtbaar
Organisatie: SYSQA B.V. Pagina 6 van 12 worden. Een voorbeeld hiervan is dat zich na een uur nog geen problemen voordoen, maar dat na vier uur problemen ontstaan doordat de niet meer gebruikte delen van het geheugen niet vrij worden gegeven ( memory leak ). Bij benchmarking worden dezelfde performancetesten uitgevoerd op verschillende configuraties van een systeem met als doel om te meten hoe een verandering in het systeem de performance beïnvloedt. Hierbij wordt bijvoorbeeld getest of het systeem nog steeds blijft voldoen aan de eis dat de responstijd van de knop Verzend niet langer dan 2 seconden is nadat een switch in het netwerk is vervangen door een ander model. 2.4.2 Stresstest Een stresstest lijkt veel op een loadtest, zie Figuur 2. De stresstest wordt ook trapsgewijs opgebouwd. Figuur 2: Opbouw stresstest Het verschil is echter dat een stresstest verder gaat dan het testen van de representatieve belasting en bewust een dusdanig hoge belasting simuleert totdat er een moment komt waarop het systeem deze belasting niet meer aan kan. Dit wordt gedaan om drie redenen: 1) om te ontdekken bij welke belasting het systeem de belasting niet meer aan kan (wanneer draait het systeem op 100%); 2) om te bepalen wat er op zo n moment gebeurt (valt het gehele systeem uit, gaan er transacties verloren, et cetera); 3) om te zien waar het knelpunt in het systeem zich bevindt. 2.4.3 Peaktest Bij een peaktest wordt het te testen systeem kortdurend erg zwaar belast, om daarna weer terug te vallen op een representatieve niveau, zie Figuur 3. Figuur 3: Opbouw peaktest Het doel van deze test is om te constateren hoe het systeem omgaat met een piek in de belasting. Zo n piek kan bijvoorbeeld ontstaan wanneer alle medewerkers binnen een
Organisatie: SYSQA B.V. Pagina 7 van 12 bedrijf na een stroomstoring tegelijkertijd hun werk hervatten of op 31 maart als heel Nederland zijn belastingaangifte inkomstenbelasting moet hebben ingediend vóór 1 april.
Organisatie: SYSQA B.V. Pagina 8 van 12 3 Aanpak performance test 3.1 Test voorbereiding 3.1.1 Omgeving en infrastructuur Om het gedrag van het systeem zo nauwkeurig mogelijk te kunnen meten is het belangrijk om de performancetest uit te voeren in een omgeving die zo veel mogelijk gelijk is aan de productieomgeving. Vaak wordt hiervoor de acceptatieomgeving of aparte performance testomgeving gebruikt. Voordat een performancetest wordt uitgevoerd is het belangrijk om de infrastructuur in kaart te brengen. Op deze manier kunnen de verschillen tussen bijvoorbeeld de acceptatieomgeving en de productieomgeving worden blootgelegd. Het is echter niet altijd mogelijk de volledige infrastructuur in de test op te nemen. Om dan toch tot een goed inzicht te komen, dienen er verschillende meetpunten gedefinieerd te worden. Per meetpunt wordt bepaald wat er gemeten gaat worden en wie de meting uitvoert. 3.1.2 Gedrag Naast het in kaart brengen van de infrastructuur dient het te verwachten gedrag van de leverancier van de input (een gebruiker of ander systeem) en de daaraan gekoppelde prestatie-eisen vastgesteld te worden. Vanuit het verwachte gedrag kunnen scenario s worden ontworpen. Hierin worden de uit te voeren handelingen gedetailleerd beschreven. Het doel van een scenario is om het gebruik van een systeem door een gebruiker of ander systeem te simuleren. Deze vastgelegde simulatie van gedrag wordt ook wel een Runbook genoemd. De eisen kunnen in de vorm van aantallen per tijdseenheid worden weergegeven, zoals vereiste en gewenste responsetijden. Er kunnen echter ook eisen zijn op het gebied van netwerkverkeer, CPU-belasting, lees- en schrijfsnelheden van databases etc. 3.2 Tooling Performancetesten kunnen handmatig worden uitgevoerd, maar vaak wordt tooling gebruikt om de performancetesten uit te voeren. Het gaat hierbij om loadtools en monitoring tools. 3.2.1 Load tooling Wat alle performancetesten gemeen hebben is dat ze een bepaalde belasting creëren. Hoewel het in theorie mogelijk is dit handmatig te doen, is er in de praktijk vaak te veel mankracht voor nodig en is de handeling niet herhaalbaar. De gebruikelijke oplossing hierbij is een tool met Record and Playback functionaliteit. Om de belasting te simuleren van een webapplicatie die werkt in een browser en draait op de achterliggende webserver, moet het http verkeer gesimuleerd worden tussen deze browser en webserver. Het is mogelijk dit handmatig uit te voeren, maar vereist in de praktijk uitgebreide en specialistische kennis om het precieze verkeer van echte gebruikers in de live situatie tussen de browser en de webserver na te bootsen. De Record and Playback functionaliteit kan worden ingezet om de eerder genoemde scenario s op te nemen (record). Daarbij wordt al het verkeer tussen de browser en de webserver geregistreerd. Vervolgens kan de tool (eventueel met handmatige aanpassingen) hier een testscript van maken, wat daarna kan worden afgespeeld (playback).
Organisatie: SYSQA B.V. Pagina 9 van 12 3.2.2 Parametriseren Wanneer het Runbook voorschrijft om het aanmaken van een nieuw gebruikersaccount 900 keer te simuleren en hiervoor telkens dezelfde opgenomen gegevens worden gebruikt, zal de server na de eerste keer een foutmelding geven. Immers, het gebruikersaccount bestaat dan al. Het script faalt dus voor user 2 tot en met 900. Een ander voorbeeld is dat databases veelgebruikte en recent opgevraagde data in de cache plaatsen. Als dan telkens hetzelfde gegeven opgevraagd wordt, dan zal alles vanaf de tweede aanvraag sneller afgehandeld worden. In beide gevallen wordt er dan een niet-representatieve belasting gecreëerd. Om dit te ondervangen is het nodig om sommige gegevens variabel te maken. Hierbij moeten parameters ingesteld worden om ervoor te zorgen dat de gegevens wel realistisch blijven. Het instellen van deze parameters is in veel gevallen een van de moeilijkste en tijdsintensieve delen van performance testen. 3.2.3 Controleren van het resultaat Om te testen of de tool goed ingesteld is, is het belangrijk om het resultaat van de handelingen te controleren. Dit zijn zowel de inhoudelijke responses als de wijzigingen in het systeem. Het is dan ook belangrijk om een controle in het script in te bouwen, zodat kan worden gekeken of de handeling daadwerkelijk leidt tot het gewenste resultaat. 3.2.4 Testen op kleine schaal Wanneer alles ingesteld is, is het verstandig om eerst de test uit te voeren met slechts enkele gebruikers. Indien er dan fouten optreden vanuit het script of de parameters, hoeft niet gewacht te worden tot het gehele script (bijvoorbeeld het aanmaken van 900 useraccounts) is doorlopen. 3.2.5 Monitoring tooling Een belangrijke taak van een performance tester is het meten van responstijden. Hiervoor worden veelal monitoring tools gebruikt. Database producten hebben bijvoorbeeld vaak eigen monitoring tools met meer specifieke informatie die beter geïnterpreteerd kunnen worden door een database-expert. Andere monitoring tools meten bijvoorbeeld CPUgebruik, database-activiteit, netwerkverkeer, memory usage, disk I/O et cetera. Het kan verleidelijk zijn om alle mogelijke variabelen te meten. Het is echter belangrijk om dit met mate te doen, aangezien het bij teveel data niet meer mogelijk is om zorgvuldig te kijken en patronen te ontdekken in de grote hoeveelheid aan data. Tevens is een selectie belangrijk om zo binnen tijd en budget te blijven. Ook moet er rekening gehouden worden met het feit dat het meten zelf ook een minieme impact heeft op de performance. Als er veel gemeten wordt, dan kan de performance door de meting zelf anders worden. Indien er genoeg tijd en geld beschikbaar is, kan er voor worden gekozen om meerdere performancetesten uit te voeren met elk een andere focus, om zo verschillende knelpunten te vinden.
Organisatie: SYSQA B.V. Pagina 10 van 12 4 Bronvermelding Documenten Mees, R. (2004) Aanpak efficiëntietesten. White paper. Witteveen, A. (2013) Performance Testing, a Practical Guide and Approach Boeken Van der Aalst, L., Broekman, B., & Koomen, T. & Vroon, M. (2006) TMap Next Artikelen (2009) Latency is everywhere and it costs you sales how to crush it. Retrieved 12 december 2014 from http://highscalability.com/latency-everywhere-and-it-costs-yousales-how-crush-it
Organisatie: SYSQA B.V. Pagina 11 van 12 Bijlage 1: Vragen aanpak performance testen A. Test voorbereiding Doelstelling Wat is de doelstelling van de performance test? Bepaal hiermee de scope en het einddoel van de performance test. Wat zijn de acceptatiecriteria van de performance van het systeem? Bepaal de acceptatiecriteria per testobject, om duidelijk te krijgen wat de performancetest moet meten. Bijvoorbeeld responstijd in seconden, netwerkbelasting, CPU-gebruik, etc. Wat gebeurt er als het misgaat? Wat mag er absoluut niet fout gaan? Denk aan kapotte servers, hersteltijd en financiële schade door down-time. Testvorm Wat voor soort performancetests willen we uitvoeren? Bijvoorbeeld loadtest (trapsgewijze toename van de belasting op het testobject), stresstest (langdurige belasting op het testobject) of peaktest (extreme bezetting binnen bepaalde tijd). Infrastructuur Is er een grafische weergave van de architectuur van het netwerk? Helpt bij het identificeren van mogelijke knelpunten en bij het oplossen van defects. Wat zijn de specificaties van het testobject / de testobjecten? In welke type omgeving werkt het, welke componenten bevinden zich binnen de omgeving, welk type applicatie waartegen getest wordt. In hoeverre is de testomgeving gelijk aan de productieomgeving? Denk aan de representativiteit van de omgeving. Is dit identiek aan productie? Veelal wordt de acceptatieomgeving of aparte performance testomgeving gebruikt. Let er op dat je ook een beeld krijgt van wat de bottleneck in de keten is; die bepaalt meestal de performance. Dus als er ergens in de keten een pc via een modem en een koperdraad aan de rest van het systeem verbonden is, dan kan de performance van het grootste deel nog zo optimaal zijn, uiteindelijk merkt de eindgebruiker een heel slechte performance door de bottleneck in de keten. Invulling testomgeving Hoe is het testobject gevuld? Denk bijvoorbeeld aan het opvragen van gegevens uit een database. Gegevens uit een bijna lege database opvragen gaat sneller dan een normaal gevulde database. Met wat voor data moet een database dan gevuld worden?
Organisatie: SYSQA B.V. Pagina 12 van 12 Belasting Om wat voor gebruikersaantallen/transacties gaat het? Is er een inschatting te maken van aantallen op basis van bestaande gegevens (wat is de piek?). Wat wordt er in de toekomst verwacht? Welke locatie hebben de gebruikers? Gedrag Wat zijn de handelingen die een gebruiker of ander systeem uitvoert? Bepaal het Runbook met realistische acties die normaal gezien door een gebruiker of ander systeem worden uitgevoerd. Maak per groep (bijv. gebaseerd op rol van gebruiker of met welk systeem er interactie plaats vindt) een eigen Runbook. B. Test uitvoering Tooling Welke criteria zijn er voor het gebruik van tooling? Licentiekosten, open of closed source? Welke tooling is geschikt om te testen? Maak afhankelijk van het type applicatie en de omgeving de keuze voor een bepaalde tool of combinatie van tools. Wat en hoe ga je meten? Denk aan metingen aan de front- en/of back-end van een systeem met betrekking tot netwerkverkeer op de testobjecten, query optimalisatie van SQL databases, etc. Planning Hoe vaak ga je een test uitvoeren en wanneer? Zijn er genoeg resources beschikbaar en kunnen er conflicten optreden met de huidige productie-omgeving? Moet er rekening gehouden worden met een geplande back-up? Is er sprake van onderhoudswerkzaamheden? Is er voldoende schijfruimte beschikbaar?