Introductie Performancetesten. versie 1.1

Transcriptie

1 Introductie Performancetesten versie 1.1

2 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 performancetesten. Performancetesten 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 performancetesten. 2 van de 16

3 Inhoudsopgave Inleiding Wat is perfomancetesten? Definitie performance Waarom performancetesten Uitganspunten performancetesten Soorten performancetesten Loadtest Stresstest Peaktest Aanpak performancetest Testvoorbereiding Omgeving en infrastructuur Gedrag Tooling Load tooling Parametriseren Controleren van het resultaat Testen op kleine schaal Monitoring tooling Bronvermelding Bijlage 1: Checklist aanpak performancetesten A. Testvoorbereiding B. Testuitvoering van de 16

4 1 Wat is perfomancetesten? In dit hoofdstuk worden verschillende definities en begrippen in hoofdlijnen besproken. Ten eerste gaan we in op wat performancetesten is. Performancetesten is een testvorm waarbij de prestaties (performance) van een systeem worden getest. Voordat we hierop ingaan wordt het begrip performance uitgelegd. 1.1 Definitie performance Performance wordt door ISO 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 interactieve- en batchtransacties afhandelt. Performancetesten is feitelijk een verzamelnaam voor verschillende testtypes, te weten loadtesten, stresstesten, peaktesten, endurancetesten en benchmarking. Endurancetesten en benchmarking kunnen ook onder loadtesten geschaard worden. De eerste drie soorten performancetesten worden in deze introductie behandeld. 1.2 Waarom performancetesten Hoewel nu is vastgesteld wat performancetesten precies is, is nog niet de vraag beantwoord waarom er eigenlijk op performance wordt getest. 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 4 van de 16

5 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 of 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 bijvoorbeeld 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 performancetesten is bijvoorbeeld het antwoord te verkrijgen op de vraag welke hoeveelheid dataverkeer een door hulpdiensten gebruikt communicatiesysteem kan verwerken. 1.3 Uitganspunten performancetesten 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 transacties, etc. Bij risicovolle componenten kan de vraag worden gesteld welke transacties en systeemcomponenten als gevolg van requirements, softwarefouten of hardwarebeperkingen 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 niet-representatieve 1 (2009) Latency is everywhere and it costs you sales how to crush it. Retrieved 12 december 2014 from 5 van de 16

6 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 welke van de punten zwaarder wegen bij de uit te voeren performancetest. 1.4 Soorten performancetesten De verschillende soorten performancetesten onderscheiden zich op het gebied van de verwachtingen van de prestaties van het testobject 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 inlogt op het systeem (indien dit wel het geval is, moet er een peaktest worden uitgevoerd, zie 2.4.3). Door middel van een loadtest wordt dus de performance van het systeem op het gebied van responstijden, doorvoer etc. getest onder een voor productie realistische belasting. Naast de standaard loadtesten kunnen er ook endurancetesten of benchmarks worden uitgevoerd. Endurancetesten is het langdurig testen van het systeem onder een representatieve belasting, om zo effecten te vinden die pas na langere tijd zichtbaar worden. Een voorbeeld hiervan is dat zich na een uur nog geen problemen voordoen, maar dat na 6 van de 16

7 vier uur problemen ontstaan doordat de niet meer gebruikte delen van het geheugen niet worden vrijgegeven ( 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. 7 van de 16

8 1.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, etc.); 3) om te zien waar het knelpunt in het systeem zich bevindt 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 8 van de 16

9 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 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. 9 van de 16

10 2 Aanpak performancetest 2.1 Testvoorbereiding Voor de aanpak van een performancetest is het belangrijk om de test zo goed mogelijk voor te bereiden. Bij de voorbereiding dienen verschillende factoren in ogenschouw te worden genomen 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 een aparte performancetestomgeving 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 te worden gedefinieerd. Per meetpunt wordt bepaald wat er wordt gemeten en wie de meting uitvoert 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 te worden vastgesteld. 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. 10 van de 16

11 2.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 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 menskracht 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 worden gesimuleerd tussen deze browser en webserver. Het is mogelijk om dit handmatig uit te voeren maar het 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) 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 t/m 900. Een ander voorbeeld is dat databases veelgebruikte en recent opgevraagde data in de cache plaatsen. Als dan telkens hetzelfde gegeven wordt opgevraagd, dan zal alles vanaf de tweede aanvraag sneller worden afgehandeld. 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 worden ingesteld 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 performancetesten. 11 van de 16

12 2.2.3 Controleren van het resultaat Om te testen of de tool goed is ingesteld, 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 Testen op kleine schaal Wanneer alles is ingesteld, 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 te worden gewacht tot het gehele script (bijvoorbeeld het aanmaken van 900 useraccounts) is doorlopen Monitoring tooling Een belangrijke taak van een performancetester is het meten van responstijden. Hiervoor worden veelal monitoring tools gebruikt. Databaseproducten hebben bijvoorbeeld vaak eigen monitoring tools met meer specifieke informatie die beter kunnen worden geïnterpreteerd door een database-expert. Andere monitoring tools meten bijvoorbeeld CPU-gebruik, database-activiteit, netwerkverkeer, memory usage, disk I/O etc. 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 worden gehouden met het feit dat het meten zelf ook een minieme impact heeft op de performance. Als er veel wordt gemeten, dan kan de performance door de meting zelf anders worden. Indien er genoeg tijd en geld beschikbaar is, kan ervoor worden gekozen om meerdere performancetesten uit te voeren met elk een andere focus om zo verschillende knelpunten te vinden. 12 van de 16

13 3 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 13 van de 16

14 Bijlage 1: Checklist aanpak performancetesten A. Testvoorbereiding Doelstelling o Wat is de doelstelling van de performancetest? Bepaal hiermee de scope en het einddoel van de performancetest. o 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. o 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 o 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 o Is er een grafische weergave van de architectuur van het netwerk? Helpt bij het identificeren van mogelijke knelpunten en bij het oplossen van defects. o Wat zijn de specificaties van het testobject / de testobjecten? In welke type omgeving werkt het, welke componenten bevinden zich binnen de omgeving, tegen welk type applicatie wordt getest. o 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 performancetestomgeving 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 14 van de 16

15 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 o 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 uit een normaal gevulde database. Met wat voor data moet een database dan gevuld worden? Belasting o 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 o 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 plaatsvindt) een eigen Runbook. B. Testuitvoering Tooling o Welke criteria zijn er voor het gebruik van tooling? Licentiekosten, open of closed source? o 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. o 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. 15 van de 16

16 Planning o Hoe vaak ga je een test uitvoeren en wanneer? Zijn er genoeg resources beschikbaar en kunnen er conflicten optreden met de huidige productieomgeving? Moet er rekening worden gehouden met een geplande back-up? Is er sprake van onderhoudswerkzaamheden? Is er voldoende schijfruimte beschikbaar? 16 van de 16