Bedrijven zijn vaak bedreven met Incident- en Problem Management. Incidenten zijn vervelend en moeten opgelost worden en vaak voorkomende incidenten zijn een probleem, waarvoor lange-termijn-oplossingen gezocht worden. Incidenten zorgen echter meestal voor meer stress. Performancetesten richt zich veelal op vroegtijdig herkennen en (zo mogelijk) afvangen van de (performance-gerelateerde) incidenten die men riskeert, wanneer de applicatie in productie wordt genomen. Zo kunnen dus op voorhand mogelijke incidenten aangepakt of zelfs voorkomen worden in productie, zodat klanten of medewerkers van het bedrijf de hinder ervan niet ondervinden. Niet verwonderlijk dat performancetesters dus Change-, Release- en, met name, Capacity Management voorbij zien komen.., zou je denken. Toch zien we ze in praktijk juist vrij weinig...
ITIL is ontwikkeld als ondersteuning voor het inrichten van beheerprocessen bij ICT-organisaties. Hierbij zijn de te behandelen gegevens voor performancetesten eigenlijk onmisbaar, met name bij het inschatten van risico’s. Ook zijn er kosten te besparen door meerdere applicaties te combineren op hetzelfde systeem; applicaties die bijvoorbeeld verschillende piekmomenten kennen, kunnen gezamenlijk één systeem efficiënt benutten. Hiervoor is er echter wel een goed overzicht nodig van de ‘normale’ capaciteit die nodig is per applicatie en kennis van welke piekmomenten een applicatie heeft en de daarbij benodigde ‘piek-capaciteit’. Dat kan je natuurlijk geleidelijk aan op productie bekijken, maar meestal wil men juist het risico niet lopen dat er op een (onberekend/onverwacht) moment van piekbelasting meerdere systemen tegelijk onderuit gaan, bijvoorbeeld bij een jaarlijks terugkerend rapportage-moment.
Capacity Management
De link tussen capaciteitsmanagement en performancetesten lijkt voor de hand liggend, maar hij blijkt in de praktijk nog regelmatig te ontbreken, of zeer indirect aanwezig te zijn. Een gevolg hiervan zou kunnen zijn dat testers een veelgehoorde ‘requirement’ ontvangen: “Hij [de nieuwe versie van de applicatie] mag niet meer [resources] gebruiken dan de oude versie.” Maar hoe test je dat, als verschillende applicaties dezelfde hardware delen en slechts een deel gewijzigd wordt?
Je zou alle onderdelen, onder gelijke load, los van elkaar kunnen testen om zo te meten hoeveel resources elk deel inneemt. Met benchmark testing kan je dit prima vergelijken, maar hierbij mis je het eventuele onderlinge effect van de verschillende functionaliteiten op elkaar. En dat kan voor vervelende verrassingen zorgen. Zeker wanneer je bijvoorbeeld zware batches gaat vergeten...
Om relevante bottlenecks te vinden bij een performancetest, waar je in productie tegenaan zou kunnen lopen, is een correcte opzet nodig van het testscenario (de loadverdeling), evenals een realistische omgeving. Met elke willekeurige loadverdeling kom je uiteindelijk bottlenecks tegen, maar als er een gebruikersscenario zeer vaak uitgevoerd wordt, waar dat in praktijk niet zo is, dan loont het wellicht niet om een oplossing te zoeken voor de bottleneck waar je dan tegenaan gelopen bent.
Niet alleen een realistische omgeving en een juiste testopzet zijn dus belangrijk. Ook goede (SMART) requirements zijn onmisbaar!
Requirements vanuit Capacity Management
Wanneer men weet dat er meerdere applicaties op een systeem draaien, wil dat helaas niet zeggen dat er ook een requirement aanwezig is die een beperking aan CPU-verbruik oplegt. Soms heeft men echter wel in productie “upper limits” ingesteld. Zo kan iemand, zo nodig, uit bed gehaald worden, wanneer het resource-verbruik boven dat limiet blijft hangen, gedurende een vastgestelde periode. Als het te testen product dan op productie tijdens piekuren ¾ van het systeem gebruikt en het limiet is ingesteld op 80%, waarom zou er dan geen requirement zijn, die stelt dat dit product maximaal 60% CPU mag gebruiken bij simulatie van piek-load?
Ook een applicatie die onder 50% CPU-verbruik blijft bij het testen, kan in productie toch voor problemen zorgen in combinatie met andere activiteit op de omgeving. Een requirement maakt de performancetester alert op dit verbruik en kan er dus direct op rapporteren, terwijl dit anders als ‘binnen de normen’ gezien kan worden. Een gemiste kans om vroegtijdig actie te ondernemen.
In de praktijk komt capaciteitsmanagement er veelal op neer dat men de systemen in de gaten houdt door middel van monitoren, waar men, bij het ondervinden van een trend in toenemend resourceverbruik, actie onderneemt. Men schaalt bijvoorbeeld de systemen op of zet via Incident- en Problem Management een actie in tot refactoring van de applicaties, om resource-verbruik te verminderen. Dit is handelen achteraf, waarbij gebruikers vaak al ergernis ondervinden aan trage respons van het systeem.
Om capaciteitsmanagement in combinatie met performancetesten goed te laten werken is het echter niet voldoende om te weten hoeveel resources er verbruikt worden in een piekmoment, maar is het ook noodzakelijk om het werkelijke gebruik van het systeem op dat moment; de verdeling van load over de verschillende functionaliteiten, goed vast te kunnen stellen. En die gegevens zijn vaak moeilijker te verkrijgen. Maar.., juist die gegevens zijn hoe dan ook van groot belang om performancetesten efficiënt uit te voeren! Waarom dan niet profiteren van alle voordelen?
Zowel capaciteitsmanagers als performancetesters kunnen profiteren van een nauwere samenwerking. Performancetesters hebben veel gegevens nodig die voor een capaciteitsmanager makkelijker beschikbaar zijn. Performancetesters leveren resultaten, op basis waarvan een capaciteitsmanager pro-actief kan handelen.
In mijn volgende blog wil ik het hebben over Configuration Management en performancetesten.
