IoT Lasttest mit MQTT und LoadRunner

Lasttest von IoT Szenarien zwischen Smart Devices und Brokern

IoT Lasttests mit MQTT und LoadRunner von Stephan Dannewitz | QMETHODS | Oktober 2017
 

Treiber der Digitalisierung

Die Digitalisierung von Gesellschaft und Wirtschaft entwickelt sich rasant. Die damit verbundenen Begriffe Internet of Things (IoT, Privatanwender) und Industrie 4.0 (I40, wirtschaftlich-industrielle Nutzung) fokussieren in diesem Kontext die zunehmende Vernetzung und Automatisierung von Geräten und Maschinen. Zielstellung ist die Erleichterung des menschlichen Alltags sowie entsprechende Effizienz- & Leistungssteigerungen in Wirtschaft und Industrie. Die Art der Kommunikation zwischen Geräten wird als Machine-to-Machine (M2M) bezeichnet.
Zukünftig wird eine riesige Anzahl an Sensoren kleine Daten-Häppchen senden bzw. empfangen, um bspw. Daten wie Temperatur, Füllstand, Abnutzungsgrad etc. miteinander auszutauschen.

IoT und I40 sprechen MQTT

Ein etablierter Standard für die Datenübertragung ist das Protokoll Message Queue Telemetry Transport (MQTT). Hierbei handelt es sich um einen Nachrichtenservice der zwischen Clients und Broker unterscheidet. MQTT wird üblicherweise über TCP/IP verwendet und benötigt für die Datenübertragung nur wenigen Bytes.
Die Clients senden zunächst eine Nachricht an den Broker (oder Gateway), auch bekannt als "publishen". Der Broker empfängt alle Nachrichten der Clients und legt diese in einem dazugehörigen Verzeichnis ab. Hat ein Client dieses Verzeichnis abonniert ("subscription"), dann sendet der Broker wiederum die dort hinterlegte Nachricht an den jeweiligen Clients.
Der Client kennt also nur sich und den Broker, während der Broker das gesamte Netzwerk an Clients kennt.
 

MQTT Lasttest 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 Lasttests ausprobieren. Als Broker verwendeten wir eine Online-Version von HiveMQ. Wir simulierten fünf Clients, welche ununterbrochen zufällige Temperaturwerte 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, Dienstgüte) Level:
 
  • 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 End-Skript. Im Init-Teil des Skripts werden die Clients initialisiert und mit dem Broker verbunden. Dabei senden die Clients auch einen "Last Will" und das QoS Level zu. Den "Last Will, zu Deutsch "Letzter Wille" oder "Testament", gibt der Broker dann weiter, falls der betreffende Client die Verbindung verliert.
Während des Lasttests wird der Action-Teil iterativ ausgeführt. In diesem Fall senden die Clients in den Channel "qmethods/temp-sensor" einen zufälligen Temperaturwert. Auch hier kann das QoS Level definiert werden. Um später die Dauer für das Senden der Nachricht inklusive der Bestätigung vom Broker zu erhalten, wurde eine Zeitmessung (Transaktion) um diese Aktion gelegt.
Im End-Skript melden sich die Clienten wieder vom Broker ab.
 
vuser_init() {
 # setup IoT client
 client = mqtt_create();
 mqtt_set_client_id(client, "{IDs}");
 mqtt_set_credentials(client, "<user>", "<password>");
 mqtt_set_lwt(client1, "qmethods/temp-sensor", 
 lr_eval_string("LW: {IDs} disconnected unexpected!"), 
 MQTT_AUTO, MQTT_QOS2, MQTT_RETAIN); 
 # connect to broker
 lr_start_transaction("Connect");
 mqtt_connect(client, "tcp://broker.mqttdashboard.com:1883");
 lr_end_transaction("Connect", LR_AUTO);
}

Action() {
 # send a IoT measure to broker
 lr_start_transaction(lr_eval_string("Publish - {IDs}"));
 mqtt_publish(client, "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() {
 # disconnect from broker
 lr_start_transaction("Disconnect");
 mqtt_disconnect(client);
 lr_end_transaction("Disconnect", LR_AUTO);
}
Code-Beispiel: Lasttest-Skript für das Senden von Daten an einen Broker via MQTT
 

Durchführung und Ergebnisse des Lasttests

Im LoadRunner Controller wurde folgendes Szenario definiert: Die IoT Clients meldeten sich im Abstand von 5 Sekunden am Broker an, senden anschließend 1 Minute lang Messwerte an den Broker mit jeweils 1 Sekunde Wartezeit zwischen dem Nachrichtenversand und melden sich dann vom Broker ab.
Die Abbildung 1 zeigt die Antwortzeiten für den Aufbau der Verbindung zum Broker (connect), das Übertragen der Messwerte (publishen) und das Beenden der Verbindung (disconnect). Auffällig ist wie teuer das Connect mit ca. 400 Millisekunden gegenüber dem Publishing und dem Disconnect mit ca. 1 Millisekunde ist.
 
IoT Lasttests mit MQTT und LoadRunner
Abbildung 1: Antwortzeit für den Aufbau der MQTT Connection mit dem Broker (QoS 0)
 
In der Abbildung 2 sind noch einmal die Antwortzeiten für das Publishen im QoS Level 0 pro Client dargestellt. Die Antwortzeiten bleiben über den Testzeitraum von 1,5 Minuten konstant bei ca. 1 Millisekunde. Das zeigt noch einmal auf, wie Ressourcen-Effizient das MQTT Protokoll ist.
 
IoT Lasttests mit MQTT und LoadRunner
Abbildung 2: Antwortzeiten für die Übertragung von Messdaten (MQTT Publish) mit QoS 0
 
In der letzten Abbildung habe ich noch einmal einen Lasttest mit dem QoS Level 2 durchgeführt. Auffällig ist, dass die Antwortzeiten im Zeitraum des Ramp-up für das Publishen deutlich höher sind als danach. Dieses Phänomen konnte ich auch durch mehrfache Ausführung des Lasttest nicht besser analysieren. Hier wäre der Einsatz eines Application Performance Management Werkzeuges auf Seiten des Brokers interessant gewesen. Das war jedoch nicht möglich, da in der Teststellung eine Online-Version von HiveMQ verwendet wurde.
Die Ergebnisse nach dem Ramp-up zeigen, dass das Publishen mit dem QoS Level 2 zwischen 50-100 Millisekunden und damit deutlich teurer als mit dem QoS Level 0 ist.
IoT Lasttests mit MQTT und LoadRunner
Abbildung 3: Antwortzeiten der Transaktionen (publishen der Temperatur) mit QoS 2
 
Die Ergebnisse nach dem Ramp-up zeigen, dass das Publishen mit dem QoS Level 2 zwischen 50-100 Millisekunden und damit deutlich teurer als mit dem QoS Level 0 ist.

IoT Lasttest Szenarien

Mit der im LoadRunner verfügbaren MQTT Unterstützung sind eine Vielzahl von praxisnahen Lasttest Szenarien im IoT Umfeld durchführbar. Die deutlichen Unterschiede bei den Antwortzeiten für Connect und Publish sowie die Verwendung verschiedener QoS Level zeigen mögliche zu untersuchende Lasttest Szenarien:
  • Stabilität und Antwortzeitverhalten des IoT Broker bei Verbindungsaufnahme (Connection) einer hohen Anzahl von Smart Devices (bspw. Wiederanlaufverhalten eines produktiven Brokers)  
  • Benchmarking der Antwortzeit für das Übertragen von Messwerten (Publishen) zum Broker bei einer hohen Anzahl paralleler Smart Devices mit unterschiedlichen Quality-of-Service Levels  
  • Lasttest zur Bestimmung des Grenzwerts (Antwortzeit, Stabilität, Durchsatz) für die Anzahl an mit einem Broker verbundenen Smart Devices (System Sizing)  
 

Fazit

Das hat mich begeistert!

  • Die Umsetzung eines Lasttest Skriptes auf Grundlage des LoadRunner MQTT-Protokolls gestaltete sich als recht simpel (siehe obiges Skript-Beispiel). Dank des übersichtlichen LoadRunner Controllers können reale IoT Lasttest Szenarien einfach konfiguriert und getestet sowie mit dem Analyzers ausgewertet werden.  
  • Durch die Möglichkeit mit unterschiedlichen Quality-of-Service Leveln zu testen können eine Vielzahl von praxisnahen Testszenarien abgebildet werden.  
  • Der LoadRunner ermöglicht die Übernahme der Lasttest Skripte in das synthetische Monitoring (MicroFocus BPM-Lösung). Somit kann die Verfügbarkeit und das Antwortzeitverhalten des Brokers in der Produktionsumgebung sehr einfach realisiert und überwacht werden.  

Das würde ich mir noch wünschen!

  • Mit der ersten Version für die MQTT Unterstützung steht aktuell nur TCP/IP als Übertragungsprotokoll zur Verfügung. Hier werden die Anforderungen aus der Industrie zeigen, inwieweit auch die Unterstützung für bspw. HTTP(S) oder Bluetooth für den Praxiseinsatz notwendig sind.  
 
Begriff MQTT in Wikipedia
LoadRunner Produktseite des Herstellers MicroFocus
MQTT Websocket-Client des HiveMQ Brokers



Ihr Kommentar zum Blog-Beitrag

Nennen Sie uns bitte Ihren Namen und E-Mail-Adresse zur Verifikation. Die E-Mail Adresse wird nicht veröffentlicht!