Tipps & Tricks

Eine spannende Herausforderung beim Modernisierung von Host-Anwendungen ist das Testen der modernisierten Anwendung unter Last. Für Web-Interfaces gibt es zahlreiche Möglichkeiten mit Lasttreibern zu arbeiten. Spezieller ist der Fall, wenn die Anwendung nach wie vor 3270-Masken anbietet, deren Performance unter Last ebenfalls verprobt werden muss. Im Folgenden möchte ich eine tolle Möglichkeit vorstellen, wie man einen Lasttest gegen eine traditionelle 3270-Oberfläche durchführen kann.

Das RTE-Plugin für JMeter von Blazemeter

In der dezentralen Welt ist JMeter ein wohlbekanntes Werkzeug zum Durchführen von Lasttest. Es ist unter der Apache License 2.0 als Opensource Produkt verfügbar. Mit JMeter kann man viele parallele User simulieren, die unterschiedlichste Eingaben tätigen, Antwortzeiten protokolieren und auswerten.

Spannenderweise gibt es für JMeter ein Plugin, welches ein 3270-Terminial simulieren kann. Damit ist es möglich, die Eingaben, die man über eine 3270-Maske vornehmen kann über JMeter zu versenden und die Antwort in Bezug auf Antwortzeit und inhaltliche Korrektheit auszuwerten. Und das Beste? Das Plugin ist ebenfalls unter der Apache License 2.0 als Opensource Projekt verfügbar: https://github.com/Blazemeter/RTEPlugin

Möglicher Arbeitsablauf

Die Readme im github des Projektes ist sehr umfangreich und beantwortet alle wichtigen Fragen im Umgang mit dem Werkzeug. Dennoch möchte ich hier kurz einen möglichen Arbeitsablauf beim Arbeiten mit dem Plugin skizzieren:

  1. Aufzeichnen einer 3270-Session mittels des Plugin-eigenen Recorders: Man startet einen einfachen 3270-Emulator und führt die zu testende Aktivität durch. Alle Eingaben werden dabei in sogenannten Samples aufzeichnet.
  2. Anpassen der aufgezeichneten Samples: Es ist sehr einfach möglich die Eingaben für bestimmte Eingabefelder aus csv-Dateien zu extrahieren und damit den Lasttest mit unterschiedlichen Daten durchzuführen
  3. Validieren der Antworten: Mittels Response Assertions kann man die Antwort vom System sehr einfach gegen einen Erwartungswert (regex) vergleichen.
  4. Mögliche Verschachtelungen einbauen: Auf bestimmte Antworten muss man gesondert reagieren. Hier bietet JMeter If-then-else-Konstrukte, um den Ablauf des Tests zu steuern
  5. Die Anzahl der parallelen Threads wählen: Das 3270-Protokoll ist sehr leichtgewichtig. Daher ist es durchaus möglich mehrere tausend 3270-Anwender von einem einzigen Lasttestrechner aus zu simulieren.
  6. Lasttest im Batch-Modus starten, um unnötigen Overhead zu vermeiden, und diesen später in der JMeter Gui auswerten.

Spannende Settings

Anbei noch ein paar Empfehlungen, wie man das Optimum aus dem 3270-Lasttest herausholen kann.

Im Batch-Modus schreibt JMeter ein Protokoll. Dieses ist standardmäßig im csv Format. Darin enthalten sind u.a. die Laufzeit des jeweiligen Samples, der Name des Samples und der timestamp des Tests im Unix-timestamp Format. Letzteres ist sehr umständlich zu handhaben, daher ist es empfehlenswert, dieses umzustellen:

Im jmeter/bin Verzeichnis in der Daten jmeter.properties folgendes Property einkommentieren:
jmeter.save.saveservice.timestamp_format=yyyy/MM/dd HH:mm:ss.SSS

Leider funktioniert dieses Setting nicht für das optionale xml-Format der Protokolldatei. In diesem fall kann man mit folgendem Perl Befehl den Timestamp umrechnen lassen:

perl -pe 's{(\d{13})}{scalar localtime($1/1000)}ge'

Richtig interessant wird das Protokoll jedoch erst, wenn man das optinale xml-Format der Protokolldatei verwendet. Hiermit ist es möglich, dass der 3270-Screen jedes Samples ebenfalls protokolliert wird. Ich kann im nachhinein also nachvollziehen, welche 3270-Maske auf welche Eingabe geliefert wurde und somit Fehler leichter identifizieren. Dafür sind folgende Einstellungen in der jmeter.properties-Datei notwendig:

jmeter.save.saveservice.output_format=xml 
jmeter.save.saveservice.response_data=true
jmeter.save.saveservice.response_message=true
jmeter.save.saveservice.samplerData=true 

Abschließend noch ein kurzer Hinweis, wie die Protokoll-Dateien ausgewertet werden können. Dazu öffnet man die JMeter-Gui mit einem leeren Test-Plan. Diesem fügt man z.B. einen Aggregate Report hinzu und kann dann dort das Logfile einlesen.