LoginVSI Performance Tools

Während diverser LoginVSI Performance Tests stelle ich immer wieder fest, dass die offiziellen Workloads für die meisten Szenarien völlig ausreichen. In einigen wenigen Umgebungen werden jedoch spezielle Anwendungen bereitgestellt, die sich auf die Performance des Gesamtsystems auswirken. Oftmals ist es nicht möglich diese Anwendungen innerhalb eines Workloads vernünftig zu starten. Ein Beispiel sind Java Anwendungen. Schaue ich mir eine laufende Sitzung eines Benutzers an, sehe ich teilweise allein für diese Anwendung einen Speicherbedarf von mehreren hundert MB. Starte ich eine solche Anwendung in einem automatisierten Workload, werden oft lediglich einige MB verwendet.

Das liegt daran, dass wir automatisiert keine Aktionen mit dieser Anwendung durchführen können da es sich um Systeme handelt auf denen wir keinen Zugriff haben oder einfach keine automatisierten Aktionen durchführen können, wollen oder dürfen. Um auch solches Verhalten in einem Workload zu simulieren, habe ich ein kleines Tool Set zusammengestellt.

In der Basisinstallation von LoginVSI ist bereits ein MemoryEater enthalten, der sich relativ komfortabel in einem Workload steuern lässt. In der vorhandenen Version funktioniert dieser jedoch nicht in RDSH, also Terminalserver Umgebungen. Sicher würde sich das umgehen lassen, ich habe hier jedoch mal recherchiert und Alternativen gefunden. Natürlich bin ich bei den Sysinternals von Mark Russinovich fündig geworden (wo auch sonst).

Mit dem kleinen Kommandozeilen Tool Testlimit lassen sich diverse Variationen von Memory Leaks simulieren. Testlimit ist als x86 oder x64 Executable direkt von der Microsoft Website verfügbar.

Der einzige Nachteil des Tool ist, dass es sich innerhalb eines LoginVSI Workloads nicht so richtig gut steuern lässt. Einmal gestartet, lässt sich der Prozess nur über CTRL – C oder über den Taskmanager “abschießen”. Deshalb habe ich hier einen kleinen Wrapper in AutoIt gebaut, der sich innerhalb eines LoginVSI Workloads etwas besser steuern lässt.

Der Vorteil ist hier, dass sich über den AutoIt Wrapper der Prozess nach einer bestimmten Zeit beenden lässt ohne weiter den Speicher zu belegen. Die GUI dient lediglich dazu, im Workload auch etwas zu sehen und eventuell über Tastaturkommandos die Werte zu ändern oder auch die Anwendung selbst zu beenden (ALT – C). Der AutoIt Wrapper als kompilierte EXE (inkl. testlimit64.exe) sowie die AutoIt Source sind ebenfalls hier erhältlich.

Gerade Browser in Verwendung mit Anwendungs-Frontends nutzen oft viele CPU Ressourcen. Ein einfacher Start der Anwendung lässt auch hier die CPU nicht wirklich arbeiten. Um diese zusätzliche CPU Last im User Process Mode zu simulieren, bietet sich CPUSTRES an. Auch dieses Tool, wie sollte es auch anders sein, kommt von den Sysinternals.

Über die 4 Threads können wir unsere vorhandene CPU so richtig stressen. Im Screenshot habe ich mal mit zwei Threads die CPU’s zu 55% ausgelastet. Da das Tool bereits mit einer GUI bereitgestellt wird, benötigen wir keinen Wrapper und können es direkt aus einem Workload ansprechen.

In den meisten Fällen erzeugen Anwendungen auch eine gewisse I/O Last, die wir mit einem einfachen Start der Anwendung nicht erreichen. Auch hier hilft uns Microsoft mit dem Tool diskspd weiter. DiskSpd ist ein äußerst anpassbares I/O Tool, mit dem Tests für Dateien, Partitionen oder physische Festplatten ausgeführt werden können.

Obwohl DiskSpd selbst ausführliche Reports liefert, können wir innerhalb eines LoginVSI Workloads für das eventuell benötigte Grundrauschen von Lese- und Schreibvorgängen sorgen.

Auch wenn es nur ein “kleiner” Test ist, sollten diese Tools nur mit äußerster Vorsicht verwendet werden, da sie die Maschine, auf der sie ausgeführt werden, einfrieren können und diese möglicherweise neu gestartet werden muss.

Happy testing.