Ein Performance Engineer möchte während eines Lasttests eine genau definierte Last auf das System bringen. In der Workload ist festgeschrieben, wie viele Testcases pro Zeiteinheit ausgeführt werden sollen. Eine Pacing-Zeit von z.B. drei Minuten bestimmt, dass ein virtueller User alle drei Minuten einen neuen Durchlauf seines Testcases beginnt und verteilt so die einzelnen Durchläufe eines Testlaufes gleichmäßig. Ist der virtuelle User fertig mit seinen Aktionen, so wartet er bis zum Ablauf der Pacing Zeit. Braucht er also eine Minute, so wartet er zwei Minuten, bis die vollen drei Minuten um sind – um bei unserem Beispiel zu bleiben. Braucht er zwei Minuten, so wartet er eine Minute, usw. Screenshot 1 veranschaulicht dieses Konzept (etwaige Think Times zwischen zwei Aktionen wurden der Einfachheit halber nicht extra eingefügt, da sie keinen Beitrag zum Verständnis des aktuellen Themas liefern):
Screenshot 1: Prinzip der Pacing-Zeit mit der Pacing-Zeit TPacing und TA1,A2,A3 als Gesamtzeit der Aktionen A1 bis A3 inklusive optionaler dazwischen liegender Think Times
Wird nun in NeoLoad die Pacing-Zeit ohne weitere Modifikationen für den Testcase festgelegt, so kommt es zu einem Problem, falls eine Aktion innerhalb des Testcases fehlschlägt. Denn dann wartet der virtuelle User nicht bis zum Ende der Pacing-Zeit, sondern startet direkt von vorne (siehe Screenshot 2). Dies hat zum einen zur Folge, dass das Konzept der gleichmäßigen Verteilung der Durchlaufstartpunkte über die gesamte Zeiteinheit nicht mehr ideal gegeben ist. Zum anderen wird aber auch die wohl definierte Workload nicht eingehalten. Bricht zum Beispiel ein Testcase mehrfach nach 30 Sekunden ab und startet neu, wurde der Testcase logischerweise wesentlich häufiger gestartet, als hätte der virtuelle User immer erst nach drei Minuten neu begonnen. In Folge davon leidet natürlich auch die Vergleichbarkeit zwischen verschiedenen Testläufen mit derselben angestrebten Workload.
Screenshot 2: Im Falle einer fehlgeschlagenen Aktion innerhalb des Testcases startet der virtuelle User sofort (!) mit einem neuen Durchlauf (mit der Pacing-Zeit TPacing und der Gesamtzeit TA1,A2,A3 aller Aktionen A1, A2 und A3 des Testcases TC010 inklusive optionaler Think Times)
Nachdem wir uns die Probleme durch diesen sofortigen Neustart nach einem Fehlschlag deutlich vor Augen geführt haben, liegt die Aufgabenstellung zur Lösung dieser Problematik klar auf der Hand: Es muss ein Weg gefunden werden, wie ein User auch nach einem Fehlschlag die erforderliche Pacing-Zeit einhält.
Eine elegante Methode ist, den Testcase innerhalb eines verschachtelten Try-Catch-Blockes auszuführen. Schlägt dann eine Aktion im inneren Try fehl, wird der dazugehörige Catch ausgeführt und bis zum Neustart eines Users gewartet, da die Pacing-Zeit des äußeren Try-Catch-Blocks zum Tragen kommt (Screenshot 3). Im Falle, dass der Testcase nicht fehlschlagt, wird der Catch übersprungen und die Pacing-Zeit des äußeren Try-Catch-Blocks zeigt des übliche Verhalten einer Pacing-Zeit bei einem erfolgreichen Durchlauf eines Testcase (Screenshot 4).
Screenshot 3: Im Falle einer fehlgeschlagenen Aktion innerhalb des inneren Try-Catch-Blocks wartet der virtuelle User mit einem neuen Durchlauf auf Grund der Pacing-Zeit des äußeren Try-Catch-Blocks (mit der Pacing-Zeit TPacing und der Gesamtzeit TTC010,CATCH der Aktionen des Testcases TC010 bis zum Fehlschlag und der Zeit im Catch inklusive optionaler Think Times)
Screenshot 4: Im Falle eines erfolgreichen Durchlaufs innerhalb des inneren Try-Catch-Blocks wartet der virtuelle User mit einem neuen Durchlauf auf Grund der Pacing-Zeit des äußeren Try-Catch-Blocks (mit der Pacing-Zeit TPacing und der Gesamtzeit TTC010 der Aktionen des Testcases TC010 inklusive optionaler Think Times)