Ik ben momenteel alweer ruim anderhalf jaar werkzaam als performancetester bij mijn huidige klant. Om de testen uit te kunnen voeren maken we daar gebruik van de tool NeoLoad. Een van de grote voordelen van deze tool ten opzichte van veel andere is de uitgebreide hoeveelheid mogelijkheden die je hebt om de acties van een virtuele gebruiker te verdelen binnen de tijd.

Thinktime methode

Standaard wordt bij het afspelen van een nog niet aangepast opgenomen script gebruik gemaakt van thinktimes. Hierbij worden de waardes gebruikt zoals die ook tijdens het opnemen. je kunt per user path (klikpad/viruele gebruiker) ook aangeven dat je de opgenomen tijden wilt vervangen door een vaste waarde. Om de test nog realistischer te maken heb je ook de mogelijkheid om de tijd variabel te maken met een willekeurige waarde +/- een percentage van de opgegeven thinktime.

Hoewel deze manier van load verspreiden in de tijd wel minst tijd kostende is, kleven er ook nadelen aan. Zo zullen de responstijden van de acties van invloed zijn op de doorlooptijd van een iteratie en dus ook de load die je op het systeem zet. Ook gelden deze thinktimes op paginaniveau, van dat wat door NeoLoad als pagina is bestempeld tijdens de opname. En dat is niet altijd hetzelfde als wat door een gebruiker als pagina wordt ervaren. Soms wordt bijvoorbeeld een favicon aanroep als als losse pagina bestempeld.

Vaste pacing op containers

Tijdens heb opnemen al bied NeoLoad je de mogelijkheid om dat wat jij ;e;en pagina vind bij elkaar te plaatsen in een container. je kunt hier een omschrijving aan geven, die het script al gelijk een stuk overzichtelijker maakt. Je hebt ook de mogelijkheid om aan iedere container een pacing waarde toe te kennen. Die is een tijd in hele seconden die aangeeft hoe lang een stap minimaal moet duren. Als je daar bijvoorbeeld 10 seconden opgeeft, dan zal die stap of de responstijden van de acties nu 1 of 9 seconden zijn altijd 10 seconden duren. Alleen als de responsetijden de 10 seconden overschrijd, dan zal de stap dus langer duren. Je moet er dus wel voor zorgen dat de waarde er eentje is die niet of zelde overschreden zal worden.

Deze manier maakt de load die wordt uitgeoefend op het testobject dus veel voorspelbaarder. Het kost dan wel iets meer werk dan de vorige manier, maar veel is dat niet. Groot nadeel van deze methode is echter wel dat, zeker als je meerdere virtuele gebruikers gelijktijdig start, je load samenvalt in een klein deel aan het begin van de opgegeven pacing tijd. Dit kun je wat verzachten door de virtuele gebruikers gespreid op te starten, maar dan zul je dingen die dan niet samenvallen ook nooit zien samenvallen. Liever heb je iets dat net als in het weld soms wel en soms niet samenvalt, bij deze methode is het bijna alles of bijna niets valt samen.

Vaste pacing op klikpad

Bij een collega heb ik ook eens een oplossing voorbij zien komen waarbij er vaste pacing is gezet op het hele klikpad, er zijn geen thinktimes of iets anders op pagina niveau aanwezig en de virtuele gebruikers worden heel erg gespreid gestart. Je verdeeld dan de load, doordat responsetijden variëren, voor iedere gebruiker anders over tijd. Door de pacing op het hele klikpad is ook de load op het testobject voorspelbaar geworden. Nadeel is wel dat de sessieduur op deze manier veel korter zal zijn dan in de productiesituatie, er zullen dus minder sessies gelijktijdig open staan. Als op dat punt een performance-bottleneck zit, dan kun je dat dus missen. Je zou dit risico kleiner kunnen maken door thinktimes, al dan niet met random variatie, toe te voegen. Dan is de sessietijd wel langer en meer productielike, maar wel afhankelijk van de responstijden en dus beperkt voorspelbaar.

Variabele pacing op containers

NeoLoad bied je ook de mogelijk om te kiezen voor “pacing duration between”, waarbij je een minimum en maximum waarde kunt opgeven voor de pacing. Dit zou moeten resulteren in een betere verdeling over de tijd van de load. Volgens Neotys zouden de waarden netjes verspreid moeten worden over de waarden van de minimum tot en met de gekozen maximum waarde. Ik had echter niet het idee dat de verdeling heel netjes over alle ms. binnen het bereik was. Ook is bij deze optie het bereik alleen in hele secondes op te geven.

Mijn best practice

In de ruim anderhalf jaar dat ik nu met NeoLoad werk heb ik verschillende manieren voorbij zien komen en uitgeprobeerd. De volgende methode is in mijn beeld de beste, al kost deze wel iets meer werk en tijd dan de anderen. Allereerst plaats ik iedere pagina tijdens het opnemen al in een container. Die pacing geef ik een vaste waarde in hele seconden, die waarde plaats ik overigens in een variabele zodat ik deze voor meerdere containers in één keer op één plek kaan aanpassen. Daarna plaats ik voor iedere container een delay, met ook hier de waarde middels een variabele. De delays zijn in tegenstelling tot de pacing in milliseconed in te stellen. De variabele vul ik niet met een vaste waarde, maar met een random waarde. De tijd dat een stap gemiddeld duurt is zo de “tijd van de pacing” + (“max waarde delay” – “min waarde delay”) / 2000. Deze tijd is tot de millisencde in te stellen. De gemiddelde tijd die een iteratie gaat duren zal dan die tijd keer het aantal containers zijn. Heb je er een stap tussen zitten die langer duur, kun je die ook los instellen.

Op basis van de load die je wilt halen, het aantal gelijktijdige sessie die je wilt halen en het aantal containers dat in het klikpad zit, kun je uitrekenen hoe lang een stap gemiddeld mag duren. Die tijd varieer ik dan +/- 20%.

Instellingen:

• Pacing: 80% van het doelgemiddelde afgerond naar beneden
• Minimum variabele pacing: Het deel tussen de waarde van de pacing en 80& van het doelgemiddelde
• Maximum variabele pacing:Het verschil tussen het doelgemiddelde + 20% en je pacing
• Ramp-up: de virtuele gebruikers start ik op verdeeld over een tijd die minimaal gelijk is aan de duur van het uitvoeren van een klikpad

Met deze methode denk ik bereikt te hebben:

• Voorspelbare load
• Voorspelbare sessieduur
• Realistisch aantal sessies gelijktijdig open
• Variatie in load
• Variatie in gelijktijdigheid