Als performance tester merk ik dat het begrip performance voor veel IT collega’s een ongrijpbaar principe blijft. Door deze ongrijpbaarheid krijgt het vaak onvoldoende of te laat aandacht. In ‘waterval’-omgevingen was ik wel gewend dat performance een ondergeschoven kindje was, waar pas vlak voor live-gang aandacht voor ontstond. Maar nu we bij Agile iedere iteratie een ‘shippable’ product opleveren, blijkt uit vele ervaringen dat performance helaas nog steeds veel te laat aandacht krijgt. Waarbij pas richting livegang (of erger…erna) gevraagd wordt om de performance even te valideren.
“even te valideren”, ik hoop dat je daardoor wordt getriggerd. Doordat performance pas laat in het traject op te pakken, zie ik het vaak mis gaan doordat er simpelweg te weinig tijd is. Performance is ongrijpbaar, maar waar zit het dan eigenlijk? Overal in de systeemketen; daarmee is performance een architecturale beslissing voor de infrastructuur (netwerk), de software en de combinatie hiervan. Vanuit een shift-left gedachte, waarbij performance eerder in het ontwerp- en ontwikkeltraject wordt meegenomen en uitgevoerd, behoren de architecten samen te werken met de performance engineer.
Vroeger zouden we alleen een PPRA (Performance Product Risico Analyse) hebben uitgevoerd, waarbij we per use case en/of bedrijfsproces het performance risico bepaalden. Daarmee beschouwden we het systeem als een samenspel van software en functionele werkprocessen, maar niet de combinatie van het complete systeem, inclusief infrastructuur, en andere afhankelijkheden. Ik merkte dat lang niet alle risico’s naar voren kwamen in een PPRA, dus is er een nieuw model nodig.
Mag ik je voorstellen aan TRICKLE. TRICKLE betekent letterlijke “To move or proceed slowely or bit by bit”, maar TRICKLE is een geheugensteuntje om teams te helpen performance risico’s te identificeren, waarbij de letters staan voor:
Task completions time (Workability)
Dit is de tijd die nodig is om een werktaak efficiënt uit te kunnen voeren in het systeem. Use cases en/of bedrijfsprocessen liggen hieraan ten grondslag en zijn een essentieel onderdeel van dit model. Dit kan ook gebruikt worden om bijvoorbeeld acceptatie criteria te definiëren. De uitgangssituatie is dat een systeem te allen tijde betrouwbaar en voorspelbaar moet zijn.
Rendering time (Efficiency)
In performance testen wordt de front-end vaak niet meegenomen, dit is onterecht. Enerzijds gaat het om de gebruikerservaring, maar anderzijds zien we ook steeds meer SPA (Single Page Application, ofwel JavaScript webapplicaties). Door SPA wordt de kwaliteit van het ontwikkelen aan de front-end veel belangrijker. Design keuzes zijn hierin van essentieel belang.
In case of emergency (Fault tolerance)
Hoe erg is een fout? Iedere omgeving kan te maken krijgen met performance problemen als gevolg van het falen van een van de componenten in je systeemketen, door overbelasting of door softwarematige fouten. Hoe gaat de applicatie om met deze fouten, en is er sprake van zelf herstellend vermogen?
Concurrent users (Stability)
De focus van performance testen ligt vaak op het aantal gelijktijdige gebruikers. Echter, schattingen zijn vaak dusdanig moeilijk dat het goed is om hierin verschillende scenario’s door te spreken. In hoeverre is er sprake van het tegelijkertijd uitvoeren van acties door verschillende gebruikers. Welke scenario’s kunnen tegelijkertijd plaatsvinden en hoe beïnvloeden ze elkaar? Verschillende aspecten van performance testen komen hier ook in naar voren: stress, duur, load en piek. Sommige systemen zijn zelfs zo ingericht dat ze pas goed gaan presteren bij meerdere gebruikers.
Kilobytes to process (Scalability)
De hoeveelheid data die een omgeving kan verstouwen is een ontwerp keuze en hangt voor een deel samen met de schaalbaarheid van software en hardware. Hoeveel data moet de omgeving (software en hardware) kunnen verstouwen en waar liggen de grenzen?
Limitations in config (Configurability)
Iedere omgeving heeft een hele set aan configuratiemogelijkheden met verschillende uitwerkingen. Hedendaagse orkestratiesystemen kennen veel verschillende instellingsmogelijkheden waarvan enkele een aanzienlijke performance impact hebben. In mijn ervaring is er geen beheerpartij die alle combinaties kent. Instellingsmogelijkheden en daarmee systeembeperkingen zijn een reële performance dreiging.
Expectations (Usability)
Dit gaat om de gebruikersverwachtingen op basis van ervaringen uit het verleden, aanbevelingen van anderen of verwachtingen van systeem. Ook beleving is een hele belangrijke, zeker als lange wachttijden onderdeel zijn van de gebruikerservaring. Een systeem moet boven alles werkbaar blijven, zeker als we het bijvoorbeeld over ‘real-time’-systemen hebben, proces deadlines of service (zoals klantenservice) performance afhankelijkheden.
Het TRICKLE model zal je helpen performance threats (dreigingen) te bepalen en daarmee meer risico’s af te vangen en de juiste testen uit te voeren. Overal in het voortbrengingsproces zal TRICKLE zorgen voor een betere beheersbaarheid van de performance. De plaatsing van dit model is zo vroeg mogelijk in het proces. Wanneer de architecten zijn begonnen is dit al toepasbaar. Later ook wel, maar hoe eerder hoe beter natuurlijk. In een Agile traject zal niet alles vanaf het begin al uitgekristalliseerd zijn, daarom is ook dit een iteratief proces.
Om alle threats in beeld te krijgen wordt een sessie met stakeholders aangeraden. De juiste mensen moeten betrokken zijn bij een PTM (Performance Threat Model) sessie. Eigenlijk is het niets anders dan de volledige systeemketen langs lopen en te bepalen wie er allemaal betrokken zijn en/of invloed hebben op de inrichting ervan. Samen een dergelijke sessie doen levert vaak veel inzichten op en zorgt voor die “common understanding” van wat er gebouwd wordt, waarvoor en wat er van verwacht wordt (performance technisch gezien).
Bij grote complexe systemen is het niet altijd raadzaam om iedereen in een enkele sessie uit te nodigen en dat telkens te herhalen bij nieuwe functionaliteit. Subgroepen zijn vaak goed in staat om gezamenlijk een inzicht te creëren in de performance risico’s.
Ik heb dit model nu zelf drie keer gebruikt, iedere keer iets aangepast, en met succes bepaald welke performancetesten er uitgevoerd moesten worden en met welke onderlinge prioriteit. We hebben ons hierbij gericht op de gehele omgeving en op die manier, nog voordat er een regel code opgeleverd was, kon de software- en applicatie architectuur aangepast worden en performancetesten gebouwd en uitgevoerd worden door ontwikkelaars en testers.
We zijn zeker nog niet klaar, het is een nieuw model dat zich nog verder zal ontwikkelen. Ideeën zijn dus van harte welkom!
