IoT und Industrie 4.0 - Lasttests mittels MQTT und LoadRunner

Erfahrungsbericht eines LoadRunner Lasttesters

IoT und Industrie 4.0 - Lasttests mittels MQTT und LoadRunner von Stephan Dannewitz | QMETHODS | Oktober 2017
 

Internet of Things oder doch Industrie 4.0 ?

Der Fokus der Digitalisierung, egal ob IoT oder Industrie 4.0, liegt auf der Vernetzung von Maschinen, Produkten und Prozessen. Das Eingreifen Allerdings sind beide nicht 100%ig miteinander vergleichbar. In der Industrie 4.0 steht die Kommunikation hochvernetzter Maschinen und zahlreicher Sensoren untereinander im Vordergrund. Diese können in ihrer Gesamtheit präzise Aussagen über den aktuellen Produktionsprozess liefern und optimieren. Diese Art der Kommunikation wird auch als Machine-to-Machine (M2M) bezeichnet.
Im Vergleich dazu ist das Internet of Things eher ein Verbraucher-orientiertes Konzept. Hierbei steht die Vernetzung von Geräten und Produkten im Vordergrund, die Informationen über den Nutzer und dessen Umgebung sammeln und mit Hilfe dieser zur Erleichterung des Alltags und zur Leistungssteigerung des Nutzers beitragen. Beispiele gibt es hier zu Hauf. Denken Sie an die Routenoptimierung von Google Maps auf Ihrem Arbeitsweg oder an den Kühlschrank der Ihnen neue Lebensmittel direkt nach Hause bestellt. Die neuen Sprachassisstenten von Amazon, Google und co. fallen auch darunter. Vernetzt mit Ihren Kalendern, Apps und anderen Diensten kann vieles über ein Gerät abgewickelt werden.
 

M2M Kommunikation

Eine riesige Anzahl an Sensoren in der Industrie 4.0 senden und/oder empfangen nur kleine Daten-Häppchen wie bspw. die aktuelle Temperatur. Genutzt wird hierbei häufig das Kommunikationsprotokoll MQTT („Message Queue Telemetry Transport“). Dabei handelt es sich um eine Art Messenger der zwischen „Clients“ und „Brokern“ unterscheidet. MQTT arbeitet dabei über TCP/IP und unterstützt auch SSL Verbindungen.
Die Clients senden zunächst eine Nachricht an den Broker bzw. das Gateway, auch bekannt als „publishen“. Der Broker empfängt alle Nachrichten der Clients (bspw. eines Temperatursensors) und legt diese in einem dazugehörigen Verzeichnis ab. Hat ein Client dieses Verzeichnis abonniert, auch bekannt als „subscriben“, dann sendet der Broker wiederum die dort hinterlegte Nachricht an den jeweiligen Client.
Der Client kennt also nur sich und den Broker, während der Broker das gesamte Netzwerk kennt.
 

Lasttest auf Basis MQTT mit dem LoadRunner

Die Lasttest-Lösung LoadRunner von MicroFocus unterstützt seit der Version 12.55 das MQTT – Protokoll. Das wollten wir natürlich direkt anhand eines kleinen Performancetests ausprobieren. Als Broker griffen wir auf den Online-Broker von „HiveMQ“ zurück. Wir nutzten fünf Clients, welche ununterbrochen zufällige Zahlen an den Broker sendeten. Jeder Client pausierte nach dem Versand einer Nachricht für eine Sekunde. MQTT unterstützt dabei drei Quality of Service (QoS) Level, zu Deutsch „Dienstgüte“.
MQTT Websocket-Client (Broker)

QoS Level 0

Die Nachricht des Clients wird gesendet, der Empfang aber nicht bestätigt. Die Nachricht kann also ankommen oder verloren gehen.

QoS Level 1

Hierbei muss die Nachricht wenigstens einmal vom Broker bestätigt werden. Geht die Bestätigung verloren, sendet der Client die Nachricht erneut. Es könnte zu Duplikaten kommen.

QoS Level 2

Dies ist die höchste Dienstgüte des MQTT – Protokolls. Die Nachrichten dürfen nur einmal empfangen und weitergeleitet werden. Duplikate und verlorene Nachrichten sind ausgeschlossen.
Um den maximalen Einfluss des QoS Levels mit in den Test zu integrieren, wurde dieser einmal mit QoS 0 und QoS 2 durchgeführt. Das Skript in LoadRunner besteht dabei aus einem Init-, Action- und Endteil. Im Init-Teil des Skripts werden die Clients initialisiert und mit dem Broker verbunden. Dabei senden die Clients auch einen Last Will, zu Deutsch „Letzten Willen“ oder „Testament“ und das QoS Level. Diese Nachricht gibt der Broker dann weiter, sollten der betreffende Client unerwartet die Verbindung verlieren.
Während des Lasttests wird der Action-Teil beliebig oft oder für einen gewissen Zeitrahmen wiederholt durchgeführt. In diesem Fall senden unsere Clienten in den Channel „qmethods/temp-sensor“ die Temperatur, die bei uns aus einer zufällig generierten Zahl besteht. Auch hier kann das QoS Level definiert werden. Um später die Dauer für das Senden der Nachricht inkl. der Bestätigung vom Broker zu erhalten, wurde eine Transaktionsklammer um diese Aktion gelegt.
Im letzten Schritt melden sich die Clienten wieder vom Broker ab.
 
vuser_init()
{
	client1 = mqtt_create();

	 mqtt_set_client_id(client1, "{IDs}");
	 mqtt_set_credentials(client1, "Benutzername", "Password");
	 mqtt_set_lwt(client1, "qmethods/temp-sensor", 
	 	lr_eval_string("LW: {IDs} disconnected unexpected!"), MQTT_AUTO, MQTT_QOS2, MQTT_RETAIN);
	
	 lr_start_transaction(lr_eval_string("Login"));

		mqtt_connect(client1, "tcp://broker.mqttdashboard.com:1883");

	lr_end_transaction(lr_eval_string("Login"), LR_AUTO);
}

Action()
{			
	lr_start_transaction(lr_eval_string("Publish - {IDs}"));
	
		mqtt_publish(client1, "qmethods/temp-sensor", lr_eval_string("{Temperatur}"), 
			MQTT_AUTO, MQTT_QOS2, MQTT_RETAIN);

	lr_end_transaction(lr_eval_string("Publish - {IDs}"), LR_AUTO);
}

vuser_end()
{
	lr_start_transaction(lr_eval_string("Logout"));

		mqtt_disconnect(client1);

	lr_end_transaction(lr_eval_string("Logout"), LR_AUTO);
}
Code-Beispiel: Skript für das Senden von Daten an einen Broker mittels MQTT
 

Durchführung und Ergebnisse des Lasttests

Im Controller des LoadRunners wurde folgendes Szenario definiert: Die Clients meldeten sich in 5s Abständen beim Broker an und setzten dann 1 min lang Nachrichten ab. Das Skript wurde dabei nicht lokal sondern über eine Dockerinstanz auf unserem ESX ausgeführt. Das Docker-Image und eine Anleitung findet ihr unter folgenden Links:
Docker-Image und Anleitung
Installation Guide von HPE
 
IoT und Industrie 4.0 - Lasttests mittels MQTT und LoadRunner
Abbildung: Antwortzeiten der Transaktionen (publishen der Temperatur) mit QoS 0
 
Für die Übertragung einer Nachricht vom IoT-Gerät zum Broker („publish“) mit dem QoS Level 0 wird in unserer Teststellung im Durchschnitt 1 Millisekunde benötigt. Das Versenden der gleichen Nachricht mit dem QoS Level 2 führt zu einem Anstieg um das 50-100-fache der Übertragungszeit. Vor allem die Bestätigung des Logins (mit QoS 2) ist recht "teuer". Das Senden der Nachrichten ab 0:35 beläuft sich auf ca. 50-60 ms. Der Einfluss des QoS-Levels auf die Performance sollte entsprechend bei der Umsetzung von IoT-Szenarien und der M2M-Kommunikation berücksichtig werden.
 
IoT und Industrie 4.0 - Lasttests mittels MQTT und LoadRunner
Abbildung: Antwortzeiten der Transaktionen (publishen der Temperatur) mit QoS 2
 
Des Weiteren ist auffällig, dass der Login mit Durchschnittlich 250 Millisekunden recht „teuer“ ist (dicke türkise Linie in der Abbildung QoS 2). Auf dem QoS Level 0 belief sich der Logiin auf ca. 50 ms. Hier sollte bei der Implementierung entsprechend darauf geachtet werden, ob die Verbindung zum Broker aufrechtzuerhalten ist oder jeweils eine neue Verbindung aufgebaut werden sollte (bspw. bei großen Intervallen zwischen den Nachrichten).
 

Fazit

Die Umsetzung eines Lasttests auf Grundlage des MQTT-Protokolls mit Hilfe von LoadRunner gestaltete sich als recht simpel. Das HPE bzw. MicroFocus direkt ein Docker-Image für den Lastgenerator zur Verfügung stellen ist ebenfalls positiv anzumerken. Dank des übersichtlichen LoadRunner Controllers können reale Lastfälle einfach und visuell ansprechend abgebildet und mit Hilfe des LoadRunner Analyzers analyisiert werden.

Vorteile

  • Durch die Unterstützung des MQTT-Protokolls in HPE LoadRunner können schnell und effektive Performancetests durchgeführt werden 
  • LoadRunner ist damit geeignet die Stabilität und Performance eines Brokers zu ermitteln 
  • Linux-Unterstützung ermöglicht bspw. den Einsatz eines Rasperry-Pi als Lasttreiber 

Nachteile

  • Nur TCP/IP möglich, kein Bluetooth 
Begriff MQTT (Wikipedia)