Systematischer Testaufbau und Testdurchführung

Um die in Teil 1 angesprochene, während der Pressekonferenz eingetretene, Verlangsamung nachzustellen, wurden die als ursächlich verantwortlich identifizierten Netzwerkstrecken durch konfigurative Anpassungen und geschickte Auswahl der Standorte der Lastgeneratoren und des Zielservers unter Last gesetzt. 

Die für die Störung verantwortliche Netzwerkstrecke sei in diesem Testaufbau die Verbindung zwischen zwei Breitbandroutern. Sie verbinden das Teilnetzwerk, in dem sich die Anwender befinden, mit dem Teilnetzwerk, in dem sich die Videostream-Server befinden. Da die Anwender bei ihrer täglichen Arbeit eine hohe Datenlast auf dieser Schnittstelle erzeugen, wurde auch in Bild 2 eine leistungsfähige Anbindung berücksichtigt. Im konkreten Testfall sorgen vier Glasfaserleitungen mit einem maximalen Datendurchsatz von jeweils 10 GBit/s für einen reibungslosen Datenaustausch. Voraussetzung für die simple Addition der Einzelleitung hin zum Gesamtdatendurch-satz dieser Anbindung ist eine gleichmäßige Verteilung der einzelnen Anfragen auf alle vier zur Verfügung stehenden Glasfaserlei-tungen. Die Systematik im aktuellen Fall lässt es nicht zu, die Kommunikation einer einzelnen Quelle auf mehrere Glasfaserleitungen aufzuteilen, daher werden mehrere Lastquellen verwendet, um den Datenstrom zu erzeugen.

Die Überwachung der Netzwerkparameter ergibt, dass die Übertragung der einzelnen Netzwerkpakete immer länger dauert, obwohl das theoretisch erwartete Limit von 40 GBit/s nicht vollständig ausgelastet ist. Diese Netzwerkstrecke soll daher gezielt und kontrolliert auf ihre Leistungsparameter hin überprüft werden.

Lesen Sie auch den anderen Beitrag der Serie „Netzwerktest mittels Lasttestwerkzeug:“:

Teil 1: Definierte Netzwerklast bewusst herbeiführen
Teil 2: Systematischer Testaufbau und Testdurchführung

Bild 2: Vereinfachte Routingstruktur innerhalb eines Netzwerkes unter Verwendung der Cisco-Darstellung. These materials have been reproduced by Sogeti Deutschland GmbH with the permission of Cisco Systems Inc. © CISCO SYSTEMS, INC. ALL RIGHTS RESERVED.

Lasttransport

Die einzelnen Teilnetzwerke, die in der vorliegenden Situation betroffen sind, werden in Bild 2 auf die relevanten Teile „Anwenderlandschaft“ und „Serverlandschaft“ reduziert. Die Topologie und die damit verbundenen Routingmöglichkeiten werden in der Realität wesentlich komplexer sein und in jedem Fall eine detaillierte Analyse durch die Fachabteilung notwendig machen. Bedingung für einen verwertbaren Test ist es, wie im abstrakten Beispiel mit technischen Mitteln dafür zu sorgen, dass die von den Lastgeneratoren gesendeten Daten vollständig über die zu testende Netzwerkstrecke abgewickelt werden. Die Verwendung der in Bild 2 blau dargestellten Netzwerkstrecke würde das Testergebnis verfälschen.

An dieser Stelle sei nur grundlegend darauf hingewiesen, dass die Berücksichtigung der verfügbaren Netzwerkstrecken eine größere Herausforderung darstellt, als deren Deaktivierung. Der Netzwerkabteilung ste-hen hierfür Routingtabellen, physikalisches Trennen sowie die Nutzung von Firewalls zur Verfügung.

Listing 1: Beispielhaftes C-Skript für eine Netzwerkanfrage an einen Webserver. Erstellt mit HP Virtual User Generator (siehe [HPLR]).

Lastquelle

Der Begriff „Lastquelle“ wird hierbei im übertragenen Sinn für den Client verwendet, der das vom „Lastziel“ angebotene Bild abruft. Hat dieses Bild eine definierte Größe und wird festgelegt, wie oft es parallel abgerufen wird, so kann einfach berechnet werden, wie viel Last auf der Schnittstelle zwischen den Netzwerken abgewickelt werden muss. Ein kleiner Aufschlag von 5 Prozent sollte für die Anfrage des Bildes selbst und Randeffekte mit eingerechnet werden. Dieser Wert dient aber nur für die grobe Konzeptionierung des Tests. Die Anzahl der virtuellen Anwender, beziehungsweise in Folge die erzeugte Gesamtlast, kann im Lasttesttool überwacht und gegebenenfalls durch den Start weiterer Instanzen der Lastgeneratoren nachgesteuert werden.

Die Infrastruktur der Lastgeneratoren und ihrer Randsysteme wurde im konkreten Fall mit Produkten aus dem HP Application Lifecycle Management erstellt. Es gibt am Markt jedoch einige Konkurrenzprodukte, die vergleichbare Anforderungen erfüllen. Listing 1 zeigt die Einfachheit eines für die-se Zwecke notwendigen Lasttestskriptes. 

Bild 3: Stagnierender Datendurchsatz trotz steigender Anzahl simulierter Benutzer.

Einbindung in den regulären Testprozess

Gerade dann, wenn wie im vorliegenden Fall bereits der Fehlerfall eingetreten ist, lässt sich dieses Verfahren natürlich nicht mehr in den regulären Testbetrieb einbinden, sondern muss in einer der wenigen Phasen von geringer Netzwerkauslastung durchgeführt werden. Die Risiken von Ausfällen in der Nacht oder an Wochenenden müssen individuell ermittelt und berücksichtigt werden.

Um dieser Zeitnot nicht ausgesetzt sein zu müssen, kann dieses Verfahren auch vorbeugend während eventuell bereits geplanter Wartungszeiträume innerhalb der Serverlandschaft durchgeführt werden.

Testdurchführung

Über die Steuerung des Lasttesttools kann ein Szenario erstellt werden, welches die Anzahl der User, die das in Listing 1 beschriebene Skript parallel ausführen, kontinuierlich erhöht. Es empfiehlt sich, die Anzahl bis zu einem unkritischen Niveau per Szenario zu regeln und dann gegebenenfalls während der Testlaufzeit manuell nachzusteuern. Der durch den Prozess erzeugte Gesamtdatendurchsatz wird von der Mehrheit der Lasttesttools in einem Livemonitor dargestellt. Parallel hierzu kann das Netzwerkteam die Monitore überwachen, die auch während der Pressekonferenz eine Verlangsamung des Paketdurchsatzes angezeigt haben.

Stagniert der Datendurchsatz trotz zunehmender Anzahl von simulierten Anwendern (siehe Bild 3), so wurde der aktuell angezeigte Wert als maximaler Datendurchsatz bestimmt. Liegt dieser unter dem erwarteten Wert, kann mittels Ausschlussverfahren die Ursache für das unerwartete Bottleneck ermittelt werden.

Ursachen für eine Differenz zwischen gemessenem und berechnetem Datendurchsatz können sein:

• Ziel unterdimensioniert: kann mittels Monitoring von Werten wie CPU, Speicher, Netzwerkdurchsatz usw. nachgewiesen werden. Eine Erweiterung des Zielsystems schafft Abhilfe
• Quelle unterdimensioniert: die Systemparameter werden von einigen Lasttesttools automatisch überwacht. Sollte dies nicht der Fall sein, so kann diese Überwachung mit Betriebssystem- Bordmitteln selbst eingerichtet werden. Eine Zuschaltung von weiteren Lastgeneratoren schafft auch hier schnelle Abhilfe.
• Ein realer Fehler im Netzwerk konnte nachgewiesen werden: Da der Test beliebig wiederholbar ist, hat das Netzwerkteam nun die Möglichkeit, den Fehler einzugrenzen und zu beheben. Während des Tests nach der Pressekonferenz wurden die ersten Punkte ausgeschlossen und das Phänomen wurde auch in den Monitoren des Netzwerkteams erneut sichtbar. Eine gezieltere Analyse der Datenströme auf allen verfügbaren Glasfaserleitungen führte letztlich zu der Erkenntnis, dass ein kleiner Fehler in der Konfiguration dazu geführt hat, dass nur zwei der vier Glasfaserleitungen genutzt wurden. Dieser Fehler hätte ohne das vorgestellte Verfahren, wenn überhaupt, nur mit höherem Aufwand nachgewiesen werden können, da er erst ab einem gewissen Datendurchsatz sichtbar wird. Erst die Pressekonferenz und schließlich der erstellte Test konnten die Voraussetzung schaffen, um diesen Fehler zu reproduzieren.

Fazit

Wie in vielen Bereichen der Qualitätssicherung bekannt, muss natürlich auch für diese Vorgehensweise eine umfassende Kosten/Nutzen-Abschätzung erstellt werden, die letztlich vom Risiko eines Ausfalls und der drohenden Beeinträchtigung des Netzwerkes beziehungsweise der resultierenden Auswirkungen abhängig ist. Dem Ausfall der Übertragung des Streams zum Server des TV-Senders, der die Pressekonferenz überträgt, wäre sicherlich eine größere Auswirkung zuzuschreiben als einem leichten Ruckeln des Videostreams an den Arbeitsplätzen der Mitarbeiter.

Spätestens im Fehlerfall kann ein guter Kontakt zwischen Experten aus dem Last- und Performanzumfeld und dem für das Netzwerk zuständigen Fachbereich nur Vorteile bringen. 

Marcel Jodorf ist als Consultant bei der Sogeti Deutschland GmbH im Bereich Softwarequalitätssicherung für einen norddeutschen Großkonzern tätig. Seine Aufgabenbereiche umfassen Beratung, Konzeptionierung, Durchführung sowie Auswertung von Last- und Performanztests für verschiedene Softwareprojekte.   

Literatur & Links

[HPLR] Hewlett Packard, LoadRunner
[Kle13] B. Klemm, Application Performance Testing: A Universal Performance Testing Metho- dology, Kindle E-Book, 2013
[Koo08] T. Koomen, L. van der Aalst, B. Broekman, M. Vroon, TMap Next, dpunkt.verlag, 2008
[LTUe] International Testing-Board, Lasttest Tools Übersicht
[Wiki-a] Wikipedia, Lasttest
[Wiki-b] Wikipedia, Rechnernetz