Comparison of data-communication technologies for a Real ...

HTWK Leipzig

Bachelorarbeit

Comparison of data-communicationtechnologies for a Real-World Business

Application

Vorgelegt von:Bastian Treitz

Matrikelnummer:69669

Erstbetreuer:Prof. Dr. Robert Muller

Zweitbetreuer:Martin Pfeiffer

Fakultat Informatik und MedienStudiengang Medieninformatik

11. November 2020

Kurzfassung

In einer Client/Server-Netzwerkarchitektur wird die Kommunikation der Kompo-

nenten durch Protokolle geregelt. Die Wahl des Protokolls hat dabei Einfluss auf die

Verzogerungszeiten im Datentransfer.

Diese Arbeit hat ausgewahlte Protokolle und Technologien fur A12 Business-Anwen-

dungen bezuglich des Aspekts der Performance getestet. Der Fokus lag auf HT-

TP/2, HTTP Long Polling, WebSockets und der AMQP-Implementierung Rab-

bitMQ. Um dies zu realisieren wurde eine Applikation entwickelt, die alle Anwen-

dungsfalle fur jede der Technologien implementiert. Die erstellten Testszenarien wur-

den daraufhin ausgefuhrt und die Ergebnisse zeigen, welche Technologien in welchen

Anwendungsfallen gut oder schlecht geeignet sind.

HTTP/2 erzielt im Vergleich gute Ergebnisse, wenn der vorliegende Anwendungs-

fall dem Request/Response-Muster entspricht. Wenn es sich zudem um große zu

sendende Objekte handelt, kann HTTP/2 Verzogerungseinsparungen von mindes-

tens 22% gegenuber den anderen getesteten Technologien vorweisen. Long Polling

erweist sich fur A12 Business-Anwendungen mit sich standig aktualisierenden Live-

Daten als keine gute Option. WebSockets hingegen stechen in diesem Fall durch

eine sehr geringe Latenz hervor, die insbesondere bei einer hoheren Anzahl von Cli-

ents uberzeugt. Hier existieren Anwendungsfalle, bei denen der WebSocket 63 %

schneller ist als die Alternativen. RabbitMQ uberzeugt durch gute Resultate in ver-

schiedensten Anwendungsfallen. Bei Live-Daten fur einen Client kann die Message

Queue mit den Latenzen des WebSockets mithalten. Erst eine Erhohung der Anzahl

der Clients bewirkt eine großer werdende Abweichung. Zudem uberzeugt RabbitMQ

mit geringen Zeiten in der Neu-Verbindung und fur A12 Business-Anwendungen

mit Request/Response-Muster. In Letzterem existieren Anwendungsfalle bei denen

RabbitMQ 10 % schneller ist als HTTP/2.

II

Inhaltsverzeichnis

1 Einfuhrung 11.1 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Grundlagen 42.1 A12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.2 Long Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 WebSocket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Message Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5 Apache JMeter™ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.6 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Anforderungsanalyse 113.1 Anwendungsfalle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1 Anfrage unabhangiger Objekte . . . . . . . . . . . . . . . . . 113.1.2 Informationsabhangigkeit . . . . . . . . . . . . . . . . . . . . . 123.1.3 Aktualisierende Daten . . . . . . . . . . . . . . . . . . . . . . 133.1.4 Mehrere Clients . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.5 Neu-Verbindung . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Nicht-funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . 163.2.1 Anpassbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.2 Erweiterbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.3 Benutzerfreundlichkeit . . . . . . . . . . . . . . . . . . . . . . 163.2.4 Reproduzierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Implementierung 184.1 Basis-Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1.1 HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.1.2 WebSocket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.3 RabbitMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2 Umsetzung der Anwendungsfalle . . . . . . . . . . . . . . . . . . . . . 224.2.1 Anfrage unabhangiger Objekte . . . . . . . . . . . . . . . . . 234.2.2 Informationsabhangigkeit . . . . . . . . . . . . . . . . . . . . . 234.2.3 Aktualisierende Daten . . . . . . . . . . . . . . . . . . . . . . 244.2.4 Mehrere Clients . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2.5 Neu-Verbindung . . . . . . . . . . . . . . . . . . . . . . . . . . 26

III

4.3 Messung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.3.1 Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3.2 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3.3 Limitierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Auswertung 295.1 Anfrage unabhangiger Objekte . . . . . . . . . . . . . . . . . . . . . . 295.2 Informationsabhangigkeit . . . . . . . . . . . . . . . . . . . . . . . . . 315.3 Aktualisierende Daten . . . . . . . . . . . . . . . . . . . . . . . . . . 335.4 Mehrere Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.5 Neu-Verbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6 Fazit 386.1 HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.2 WebSocket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.3 RabbitMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Quellenverzeichnis 41

A Anhang 44A.1 Testdurchfuhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44A.2 Messergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

IV

Abbildungsverzeichnis

2.1 HTTP Request/Response Muster uber TCP . . . . . . . . . . . . . . 42.2 Vergleich des HTTP Request/Response Musters ohne und mit Mul-

tiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 HTTP Long Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Beispiel WebSocket Handshake eines Clients und eines Servers mit

Upgrade- und Connection-Header . . . . . . . . . . . . . . . . . . . . 72.5 RabbitMQ Pub/Sub System . . . . . . . . . . . . . . . . . . . . . . . 92.6 Simpler Beispiel-Testfall in JMeter . . . . . . . . . . . . . . . . . . . 9

3.1 Anwendungsfall 1 - Use-Case Diagramm . . . . . . . . . . . . . . . . 123.2 Anwendungsfall 2 - Use-Case Diagramm . . . . . . . . . . . . . . . . 133.3 Anwendungsfall 3 - Use-Case Diagramm . . . . . . . . . . . . . . . . 143.4 Anwendungsfall 4 - Use-Case Diagramm . . . . . . . . . . . . . . . . 153.5 Anwendungsfall 5 - Use-Case Diagramm . . . . . . . . . . . . . . . . 16

4.1 Client/Server Architektur auf deren Basis die Anwendungsfalle im-plementiert werden . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.1 Latenzen, abhangig von der Objektanzahl . . . . . . . . . . . . . . . 305.2 Latenzen, abhangig von der Objektgroße . . . . . . . . . . . . . . . . 315.3 Latenzen, abhangig von dem Anteil der Objekte mit Informations-

abhangigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.4 Latenzen, abhangig von der Große des Intervalls, in dem sich Daten

aktualisieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.5 Latenzen, abhangig von der Anzahl der Clients . . . . . . . . . . . . . 355.6 Zeit zwischen einem Verbindungsabbruch und der erneuten Verbin-

dungsherstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

V

Tabellenverzeichnis

4.1 Spezifikation der Hardware . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1 Parameter fur Anwendungsfall 2 . . . . . . . . . . . . . . . . . . . . . 325.2 Parameter fur Anwendungsfall 3 . . . . . . . . . . . . . . . . . . . . . 335.3 Parameter fur Anwendungsfall 4 . . . . . . . . . . . . . . . . . . . . . 35

A.1 Aktive Profiles nach Anwendungsfall und Technologie . . . . . . . . . 45A.2 Messergebnisse [in ms] fur Anwendungsfall 1 nach Objektanzahl -

HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46A.3 Messergebnisse [in ms] fur Anwendungsfall 1 nach Objektanzahl -

WebSocket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46A.4 Messergebnisse [in ms] fur Anwendungsfall 1 nach Objektanzahl -

RabbitMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47A.5 Messergebnisse [in ms] fur Anwendungsfall 1 nach Objektgroße - HTT-

P/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47A.6 Messergebnisse [in ms] fur Anwendungsfall 1 nach Objektgroße - Web-

Socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47A.7 Messergebnisse [in ms] fur Anwendungsfall 1 nach Objektgroße - Rab-

bitMQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48A.8 Messergebnisse [in ms] fur Anwendungsfall 2 - HTTP/2 . . . . . . . 48A.9 Messergebnisse [in ms] fur Anwendungsfall 2 - WebSocket . . . . . . 48A.10 Messergebnisse [in ms] fur Anwendungsfall 2 - RabbitMQ . . . . . . 48A.11 Messergebnisse [in ms] fur Anwendungsfall 3 - HTTP Long Polling . . 48A.12 Messergebnisse [in ms] fur Anwendungsfall 3 - WebSocket . . . . . . . 49A.13 Messergebnisse [in ms] fur Anwendungsfall 3 - RabbitMQ . . . . . . . 49A.14 Messergebnisse [in ms] fur Anwendungsfall 4 - HTTP Long Polling . 49A.15 Messergebnisse [in ms] fur Anwendungsfall 4 - WebSocket . . . . . . . 50A.16 Messergebnisse [in ms] fur Anwendungsfall 4 - RabbitMQ . . . . . . 50A.17 Messergebnisse [in ms] fur Anwendungsfall 5 - WebSocket . . . . . . . 50A.18 Messergebnisse [in ms] fur Anwendungsfall 5 - RabbitMQ . . . . . . . 50

VI

Verzeichnis der Quellcodes

4.1 HTTP-Endpunkt fur Pfad /”bei Request mit GET-Methode . . . . . 194.2 Konfiguration eines WebSockets mit STOMP . . . . . . . . . . . . . . 204.3 Konfiguration einer DirectExchange und einer Queue, die uber ein

Binding mit Routing-Key verbunden sind . . . . . . . . . . . . . . . . 22A.1 docker-compose-Konfiguration fur die Spring Boot-Anwendung . . . . 45A.2 docker-compose-Konfiguration fur Apache JMeter . . . . . . . . . . . 45

VII

Einfuhrung

1998 musste die NASA den Start eines Satelliten um mehr als acht Monate ver-

schieben und damit gravierende Kosten auf sich nehmen, da die Performance einer

Einheit zur Durchfuhrung von wissenschaftlichen Experimenten nicht ausreichend

war [1]. Nur ein Jahr zuvor zahlte der Online-Broker Merrill Lynch & Co bis zu

10 Millionen US-Dollar an Investoren als Kompensation fur Verzogerungen beim

Aktienkauf. Aufgrund von Performance-Problemen wurden die aktuellsten Informa-

tionen uber Aktien nicht an die Investoren ubermittelt, was zu großen Verlusten

fuhrte [2].

Dies sind nur zwei Beispiele, die verdeutlichen, wie essenziell Performance als Quali-

tatsattribut in Software ist und welchen wirtschaftlichen Einfluss sie auf Unterneh-

men haben kann. Konsequenzen langsamer Software reichen von verlorenem Ein-

kommen und dem Scheitern gesamter Projekte, bis zu potenziell lebensbedrohlichen

Situationen, wie beispielsweise in der Luftfahrtindustrie.

Es gibt viele Grunde, warum Software schlecht performen kann: Algorithmen sind

schlecht implementiert, die Architektur wurde nicht vorteilhaft gewahlt, die Last-

ver-teilung nicht beachtet oder es existieren allgemeine Probleme beim Networ-

king.

Viele Applikationen nutzen die Client/Server-Netzwerkarchitektur, die die Kommu-

nikation zwischen einer Client-Komponente und einer Server-Komponente bedingt

[3]. Bei der Datenubertragung sind hier ublicherweise moglichst geringe Verzoger-

ungen erwunscht.

Die Datenubertragung verlauft auf Grundlage von Transportprotokollen. Oftmals ist

dieses das Transmission Control Protocol (TCP). Daruber kann in der Anwendungs-

schicht eine Hypertext Transfer Protocol (HTTP) -Verbindung liegen, die Anfragen

an den Server sendet und auf Antworten wartet. Eine Alternative ist das WebSocket-

Protokoll, welches eine asynchrone, bidirektionale Kommunikation bie-tet. Der Ser-

ver kann somit im Vergleich zu HTTP bei bestehender Verbindung unaufgefordert

Daten an den Client senden, ohne auf Antworten warten zu mussen. Es existieren

jedoch weitere Optionen wie Message Broker, die Message Queues managen und auf

Grundlage des Publish/Subscribe-Musters Asynchronitat ermoglichen oder HTTP

Long Polling, welches uber HTTP eine Client/Server-Verbindung auf-rechterhalt bis

1

1. Einfuhrung

die angeforderten Daten vom Server bereitgestellt werden [4].

Die Wahl der Technologie zum Datenaustausch ist in vielen Fallen nicht offensicht-

lich und hangt von jedem Anwendungsfall ab. Der Kooperationspartner mgm tech-

nology partners hat in der Entwicklungsplattform A12 eine real-world Anwendung

mit verschiedensten Anwendungsfallen. Da die Performance bei A12 von hoher Re-

levanz ist, sollten hier diverse Kommunikationsmoglichkeiten zwischen Clients und

Servern im Detail betrachtet und fur jeden Anwendungsfall individuell bewertet

werden.

1.1 Zielsetzung

Das Ziel dieser Arbeit ist es fur verschiedene Anwendungsfalle ausgewahlte Techno-

logien zum Datenaustausch zwischen Clients und Servern bezuglich der Performance

und Eignung zu vergleichen und zu bewerten. Der Fokus wird dabei in dieser Arbeit

auf HTTP/2, HTTP Long Polling, WebSockets und Message Queues liegen.

Um dies zu realisieren, wird eine Anwendung entwickelt, welche die Funktionalitaten

aller ausgewahlten Technologien integriert hat. Jeder Anwendungsfall soll in dem

System mit jeder ausgewahlten Technologie realisiert sein. So konnen fur individu-

elle Szenarien die Resultate aller Technologien miteinander verglichen und einzeln

bewertet werden.

Als Client soll das Test-Werkzeug Apache JMeter dienen. JMeter ist eine open source

Software, deren Zweck das Testen von funktionalem Verhalten und Performance ist

[5]. Bei der Ausfuhrung der erstellten Testszenarien findet hier das Messen von

Metriken im Hintergrund statt [6].

Diese Bachelorarbeit soll auf Grundlage der Resultate der Testszenarien beantwor-

ten, wie gut die Technologien fur bestimmte Anwendungsfalle geeignet sind, wenn

Performance ein elementarer Aspekt der Software ist. Weitere Faktoren, die bei

individuellen Anwendungsfallen eine Rolle spielen konnten, sowie der Entwicklungs-

aufwand, sollen auch in die Bewertung einfließen.

1.2 Gliederung der Arbeit

Im Kapitel Grundlagen wird in die wichtigsten Komponenten, Protokolle und Tech-

nologien eingefuhrt, die zum Verstandnis der folgenden Kapitel dieser Abschluss-

arbeit vorausgesetzt werden. Anschließend werden auf Basis der zugrundeliegenden

Anwendungsfalle, im Kapitel Anforderungsanalyse, die funktionalen Anforderungen

an das zu entwickelnde System beschrieben und durch nicht-funktionale Anforderun-

gen erganzt. Das Kapitel Implementierung wird daraufhin die Entwicklung der zuvor

beschriebenen Anforderungen erlautern und dabei auf die beiden Hauptkomponen-

ten Test-System und JMeter eingehen. Da die Tests einen elementaren Aspekt der

Implementierung verkorpern, wird in diesem Kapitel ebenfalls darauf eingegangen,

2

1. Einfuhrung

wie die Testumgebung definiert ist. Im anschließenden Kapitel Auswertung werden

die Ergebnisse der Tests vorgestellt und mogliche Erklarungen dafur gesucht. Die

Abschlussarbeit endet mit einem Fazit, in dem die Erkenntnisse fur jede Technologie

zusammengefasst werden.

3

Grundlagen

2.1 A12

Seit 2012 entwickelt das Unternehmen mgm technology partners GmbH die Ent-

wicklungsplattform A12. Sie ermoglicht es Business-Analysten, unter Nutzung von

speziellen Editoren große Teile von Geschaftsanwendungen selbststandig zu entwi-

ckeln, wodurch die Entwicklungszeit deutlich beschleunigt wird [7]. A12 ist modell-

getrieben und die damit entwickelten Business-Anwendungen sind webbasiert und

nutzen eine Client/Server-Anwendungsinfrastruktur.

2.2 HTTP

Das Hypertext Transfer Protocol (HTTP) ist ein zustandsloses Request/Response

Protokoll auf der Anwendungsschicht. Das Protokoll wird seit 1990 fur das World

Wide Web genutzt, um Daten als Nachrichten uber Netzwerke auszutauschen [8].

Beim Client/Server Messaging sind Client und Server jeweils Programme, bei de-

nen der Client eine Verbindung mit einem Server aufbaut, um HTTP-Requests zu

senden, wahrend dieser andere Verbindungen akzeptiert und auf HTTP-Requests

mit HTTP-Responses reagiert. Verbindungen bestehen in den meisten Fallen uber

das Transmission Control Protocol (TCP) in der Transportschicht [9], wie in Grafik

[2.1] dargestellt.

Abbildung 2.1: HTTP Request/Response Muster uber TCP

4

2. Grundlagen

2.2.1 HTTP/2

Seit Mai 2015 ist HTTP/2 der verbesserte Nachfolger von HTTP/1.1. Wahrend

Kern-Funktionalitaten erhalten blieben, wurde das Protokoll in vielen Bereichen

verbessert und erweitert und bietet erhohte Effizienz [10].

Zu den wichtigsten Verbesserungen gehoren:

• Server push: Der Server kann antizipieren welche Ressourcen der Client

benotigt und sendet diese ohne vorhergehende Anfrage [11].

• Header-Komprimierung: Redundante Header-Daten werden komprimiert,

sodass Requests in vielen Fallen eine geringere Große haben oder mehrere

Requests in ein Paket mit nur einem Header komprimiert werden [10].

• Multiplexing: Mehrere Requests konnen uber eine einzige TCP-Verbindung

versendet werden und Responses mussen nicht in derselben Reihenfolge an-

kommen. Der Overhead fur den TCP-Verbindungsaufbau fallt damit weg [11].

(a) HTTP Request/Response ohne Mul-tiplexing

(b) HTTP Request/Response mit Mul-tiplexing

Abbildung 2.2: Vergleich des HTTP Request/Response Musters ohne und mit Mul-tiplexing

5

2. Grundlagen

2.2.2 Long Polling

HTTP Long Polling funktioniert auf Basis von regularen HTTP-Requests. Anstatt

jedoch sofort eine Response vom Server zu erwarten, halt dieser die HTTP-Verbin-

dung offen und antwortet erst, wenn neue Ereignisse zu senden sind. Falls das im

festgelegten Timeout nicht passiert oder die neuen Daten den Client als Response

erreichen, wird unmittelbar ein neuer Request gesendet, der wieder offen bleibt, bis

neue Ereignisse verfugbar sind oder der Timeout erreicht wird [12]. Dadurch wird

der Eindruck vermittelt, der Server wurde neue Daten unaufgefordert in Echtzeit an

den Client senden.

Abbildung 2.3: HTTP Long Polling

2.3 WebSocket

2011 standardisierte die Internet Engineering Task Force (IETF) das WebSocket-

Protokoll. Die Motivation, dieses Protokoll zu kreieren, lag darin eine bidirektionale

Kommunikation zwischen Client und Server zu ermoglichen. Bis dahin konnte Bidi-

rektionalitat durch HTTP nur nachgeahmt werden, es ist jedoch nicht ausgelegt fur

diese Art der Kommunikation und stoßt deshalb an Grenzen und Probleme [siehe

[13] Kap. 1.1].

6

2. Grundlagen

Eine WebSocket-Verbindung nutzt eine einzelne TCP-Verbindung, um Nachrichten

in beide Richtungen auszutauschen. Da das Protokoll dieselben Ports wie HTTP und

HTTPS nutzt, verlauft der initiale Handshake uber HTTP. Ein Beispiel ist in Abb.

2.4 gegeben. Der Client Upgrade- und Connection-Header, zusammen mit weiteren

WebSocket spezifischen Headern an den Server. Antwortet der Server nun ebenfalls

mit einem Upgrade- und Connection-Header, konnen Daten unabhangig voneinander

und bidirektional ausgetauscht werden [13]. Dadurch konnen beispielsweise Echtzeit-

Funktionalitaten fur Anwendungen ermoglicht werden.

(a) WebSocket Handshake des Clients (b) WebSocket Handshake des Servers

Abbildung 2.4: Beispiel WebSocket Handshake eines Clients und eines Servers mitUpgrade- und Connection-Header

Als Erweiterung des WebSocket-Protokolls kann das Simple Text Oriented Messa-

ging Protocol (STOMP) genutzt werden. STOMP definiert ein textbasiertes Wire-

Protokoll fur Nachrichten, die zwischen einem Client und einem Server ausgetauscht

werden [14]. Ein Frame besitzt ein Kommando und eine Anzahl von optionalen Hea-

dern. Ein STOMP Server hat sogenannte Destinations, an die Nachrichten gesendet

werden konnen. Die Server-Implementierung routet die Nachrichten bei Erhalt an

die entsprechenden Destinations. Ein Consumer abonniert die gewunschten Destina-

tions uber ein SUBSCRIBE-Frame und erhalt Nachrichten uber MESSAGE-Frames

[14].

2.4 Message Queue

Message Queues sind Nachrichtenwarteschlangen, um die Kommunikation zwischen

Anwendungen zu erleichtern. Zu ubermittelnde Daten werden als Nachrichten von

einer Anwendung in die Queue geschrieben und verweilen dort, bis sie von einer

Anwendung konsumiert und verarbeitet werden. Die Message Queue fungiert somit

als Puffer zwischen Anwendungen [15].

Einige der Vorteile dieser Architektur sind [15]:

• Entkopplung: Applikationen konnen vollig entkoppelt voneinander sein und

trotzdem miteinander kommunizieren, da lediglich Verbindungen zur Queue

bestehen

• Asynchronitat: Producer haben nur die Aufgabe Nachrichten an die Queue

zu senden, interessieren sich jedoch nicht dafur wann die Aufgaben vom Consu-

mer ausgefuhrt werden und ob eventuell Daten zuruckgesendet werden sollen

7

2. Grundlagen

• Concurrency: Queues speichern und stellen Nachrichten nach dem First In

- First Out Prinzip bereit. Senden somit mehrere Producer gleichzeitig Nach-

richten an die Queue ist sichergestellt, dass die erste Nachricht auch zuerst

konsumiert wird

• Persistenz: Nachrichten werden erst aus der Queue geloscht, wenn ein Con-

sumer diese konsumiert hat. Falls ein Consumer nicht bereit ist die Nachricht

entgegenzunehmen, verbleibt diese einfach etwas langer in der Queue. Es wird

somit garantiert, dass der Consumer die Nachricht erhalt. Zusatzlich wird si-

chergestellt, dass die Nachricht nur einmal konsumiert wird

RabbitMQ

Viele Message Queues werden von einem Message Broker (auch Queue Manager

genannt) verwaltet. Ein Broker kann eine Anzahl von Queues hosten und Nachrich-

ten an die gewunschten Queues routen. Zusammen agieren Message Queue und

Broker dann als Vermittler zwischen Applikationen.

RabbitMQ ist einer der popularsten open source Message Broker und implemen-

tiert den offenen Standard fur Message Oriented Middleware (MOM) Kommunika-

tion, das Advanced Message Queuing Protocol (AMQP). Ein AMQP System besteht

zusatzlich zu einem Broker und einer Message Queue aus folgenden Komponenten

[16]:

Producer Ein Programm, das Nachrichten erstellt und diese an eine Exchange

eines Brokers sendet

Consumer Ein Programm, das ein oder mehrere Message Queues deklariert und

von dort Nachrichten konsumiert

Exchange Eine Routing-Engine, die Nachrichten von Producern erhalt und diese

auf keine oder mehrere Message Queues routet

Nachrichten von Producern erreichen zunachst immer eine Exchange. Die Exchange

sorgt uber einen Routing Key dafur, dass die Nachrichten die richtigen Queues er-

reichen. Queues sind mit Exchanges uber Bindings verbunden [17].

2.5 Apache JMeter™

JMeter ist ein open source Testwerkzeug von Apache Es wurde kreiert, um die

Performance und das funktionale Verhalten von Anwendungen zu testen [6]. Es

kann genutzt werden um schwere Last auf einem Server, Gruppen von Servern und

Netzwerken zu simulieren oder um die allgemeine Performance unter verschiedenen

Arten von Lasten bei diversen Testfallen zu testen [5].

JMeter bietet standardmaßig die Moglichkeit, verschiedenste Anwendungen, Server

und Protokolle zu testen. Dazu zahlen:

8

2. Grundlagen

Abbildung 2.5: RabbitMQ Pub/Sub System

• Web-Anwendungen mit HTTP/HTTPS

• REST Webservices

• Datenbanken mit Java Database Connectivity (JDBC)

• Mail mit SMTP, POP3, IMAP

Daruber hinaus gibt es Plugins fur weitere Testmoglichkeiten:

• HTTP/2

• WebSocket

• AMQP

Testplane werden direkt in JMeter erstellt, indem die gewunschten Konfigurationen,

Controller und Sampler als Baumstruktur eingefugt werden. Ein simples Beispiel

zeigt Abb. 2.6.

Abbildung 2.6: Simpler Beispiel-Testfall in JMeter

In diesem Beispiel werden zunachst alle Benutzervariablen fur jeden gestarteten

Thread initialisiert. Konfigurationen bezuglich der Threads finden im Element Thread

Group statt. Daraufhin wird in einem Loop ein HTTP GET-Request an http://lo-

calhost:8080/my-path gesendet und direkt danach der aktuelle Thread fur eine

festgelegte Zeit pausiert. Diese Konfiguration findet in Think Time statt.

9

2. Grundlagen

2.6 Docker

Docker ist eine der verbreitetsten Container-Technologien fur Anwendungen [18].

Eine containerisierte Applikation ist isoliert von anderen Prozessen und beinhal-

tet deshalb die gesamte Umgebung, die die Applikation zur Ausfuhrung benotigt,

inklusive aller Dependencies [19]. Durch die Festlegung der Umgebung haben Ent-

wickler die Konsistenz und Sicherheit, dass die Anwendung unabhangig vom System

funktioniert. Der Code ist somit portabler und Ausfuhrungen simpel reproduzierbar

[20].

Docker-Container unterscheiden sich von Virtual Machines (VM), da Container

keine Hardware simulieren oder ein eigenes Betriebssystem nutzen. Dahingegen

teilen sich Container bestimmte System-Ressourcen und sind dadurch lightweight

[21].

Die Entwicklung von Docker-Container-basierten Anwendungen verlauft in einem

definierten Workflow. Nachdem die Anwendung programmiert wurde, muss ein Docker-

file erstellt werden. Ein Dockerfile ist eine textbasierte Datei, die ein Rezept festlegt,

wie aus der Anwendung ein Docker image erstellt werden soll. Das Docker image

kann daraufhin in einem isolierten Container direkt uber einen [docker run]-Befehl

oder wahlweise durch eine docker-compose-Datei gestartet werden [21]. In letzterem

konnen auch mehrere Container gleichzeitig gestartet werden.

10

Anforderungsanalyse

Ziel dieser Anforderungsanalyse ist es, die Anforderungen an den JMeter-Client und

das Test-System zu identifizieren und zu beschreiben. Hierfur werden zunachst in

[3.1] die Anwendungsfalle einzeln vorgestellt und anschließend dessen resultierende

funktionale Anforderungen an die jeweiligen Systeme formuliert. Erganzt werden

diese in [3.2] durch nicht-funktionale Anforderungen.

3.1 Anwendungsfalle

In diesem Abschnitt werden die unterschiedlichen Anwendungsszenarien von A12

fur die Interaktion zwischen einem oder mehreren Apache JMeter-Clients und dem

Test-System vorgestellt. Zum besseren Verstandnis wird jeder Anwendungsfall durch

ein Beispiel vervollstandigt. Da A12 eine modellgetriebene Plattform ist, werden

Business-Anwendungen durch die Modelle bestimmt. Unterschiedliche Modelle konnen

somit unterschiedliche Anwendungen simulieren, weshalb es moglich ist, die gewahlten

Anwendungsfalle synthetisch zu gestalten. Die von den Anwendungsfallen abgelei-

teten Anforderungen beschreiben funktionale Anforderungen.

3.1.1 Anfrage unabhangiger Objekte

Ein Client benotigt unmittelbar Daten vom Server. Diese Daten bestehen aus einer

Anzahl von Objekten mit einer festen Große. Die Objekte sind unabhangig vonein-

ander und sollen schnellstmoglich vom Server zum Client gesendet werden, nachdem

sie von diesem angefragt wurden. Je nach Testfall variiert die Anzahl der benotigten

Objekte und die feste Große eines einzelnen Objekts.

Beispiel:

Eine Social-Media-Applikation, bei der nach Aufruf des ”FreundeMenupunkts die

Profilbilder aller Personen in der Freunde-Liste angezeigt werden sollen.

Der Client soll:

• eine Anzahl von Objekten anfragen

11

3. Anforderungsanalyse

Das System soll:

• eine Anzahl von Objekten mit fester Große an den Client senden

FrageunabhangigeObjekte an

Sende Objektean Client

Client Server

Abbildung 3.1: Anwendungsfall 1 - Use-Case Diagramm

3.1.2 Informationsabhangigkeit

Ein Client benotigt eine Anzahl von Objekten vom Server. Zwischen einem be-

stimmten Anteil der Objekte besteht eine Abhangigkeit. Der Client benotigt somit

zunachst Informationen von einem Objekt, bevor das von diesen Daten abhangige

Objekt angefragt werden kann.

In diesem Anwendungsfall variiert der Anteil von Objekten, die von anderen abhangig

sind.

Beispiel:

In einer Social Media-Anwendung sollen in einer Tabelle mit zwei Spalten Infor-

mationen angezeigt werden. Die erste Spalte zeigt die Profilbilder aller Personen

und das jeweilige Datum des Hinzufugens dieser Person zu der Freunde-Liste an. In

der anderen Spalte sind zusatzliche Informationen uber die jeweilige Person, wenn

diese in den vergangenen 7 Tagen zur Freunde-Liste hinzugefugt wurde, zu sehen.

Aufgrund potenzieller großer Mengen an Personen in der Freunde-Liste, werden die

Profilbilder, inklusive Datum, einzeln fur jede Person angefragt. Fur jede Person,

bei dem das Datum in dem genannten Zeitraum von maximal 7 vergangenen Tagen

liegt, wird eine weitere Anfrage getatigt, um die zusatzlichen Informationen in der

weiteren Tabellenspalte anzuzeigen. Hat ein Nutzer beispielsweise 100 Freunde in

der Anwendung und 50% der Freunde wurden in den letzten 7 Tagen hinzugefugt,

werden insgesamt 100 unabhangige und 50 abhangige Anfragen getatigt. Der Anteil

abhangiger Objekte liegt damit bei 1/3.

Der Client soll:

• eine Anzahl von Objekten anfragen

• bei Erhalt von bestimmten Daten davon abhangige Objekte anfragen

12


Das System soll:

• auf Anfragen reagieren und die Objekte an den Client senden

FrageunabhangigeObjekte an

FrageabhangigeObjekte an


Client Server


3.1.3 Aktualisierende Daten

Das System besitzt Daten, die sich in einem nicht-periodischen Intervall aktualisie-

ren. Die neuen Daten stammen von einem Client, der diese an den Server sendet.

Abhangig von weiteren Faktoren kann das Intervall mehrere Sekunden, oder nur

Bruchteile von Sekunden, betragen. Ein weiterer Client benotigt diese neuen Daten,

sobald sie bereitstehen.

Beispiel:

Eine Chat-Anwendung, in der man mit einzelnen Personen Nachrichten austauschen

kann. Nachdem eine Person eine Nachricht sendet, soll diese den Empfanger ange-

zeigt werden.

Client 1 soll:

• in bestimmtem Intervall Daten zur Aktualisierung an den Server senden

Client 2 soll:

• aktualisierte Daten schnellstmoglich erhalten

Das System soll:

• veraltete Daten aktualisieren, sobald neue Daten das System erreichen

• aktualisierte Daten fur Client 2 bereitstellen/weiterleiten

13


Daten anServersenden

AktuelleDatenerhalten

AktuelleDaten

bereitstellen/ weiterleitenClient 1

Client 2

Server


3.1.4 Mehrere Clients

Das System besitzt wie in [3.1.3] Daten, die sich in einem bestimmten Intervall ak-

tualisieren. Die neuen Daten stammen von einem Client, der diese in einem Intervall

an den Server sendet. Dieser Anwendungsfall wird getrennt von [3.1.3] betrachtet,

da hier das Test-System isoliert auf Veranderungen der Ergebnisse bei variieren-

der Anzahl von Clients getestet wird. Die Anzahl der Clients, die die aktuellen

Informationen benotigen, ist somit in diesem Anwendungsfall die Variable, wahrend

es immer nur einen Client gibt, der die Daten zur Aktualisierung an den Server

ubermittelt.

Beispiel:

Eine Anwendung, um Verlaufe des Aktienmarkts zu beobachten. Alle Nutzer, die

in dem Moment online sind, sollen bei Anderungen im Verlauf, die Aktualisierung

erhalten und damit wieder auf dem aktuellsten Stand sein.

Client 1 soll:

• in bestimmtem Intervall Daten zur Aktualisierung an den Server senden

Weitere Clients sollen:

• aktualisierte Daten schnellstmoglich erhalten

Das System soll:

• Daten aktualisieren, sobald es moglich ist

• aktualisierte Daten fur alle Clients bereitstellen/weiterleiten

14


Daten anServersenden

AktuelleDatenerhalten

AktuelleDaten

bereitstellen/ weiterleitenClient 1

Weitere Clients

Server


3.1.5 Neu-Verbindung

Ein Client benotigt Objekte vom Server. Bei der Ubertragung der Daten kommt es zu

einem Verbindungsabbruch, was die sofortige Neu-Verbindung des Clients erfordert.

Sobald die Verbindung wieder besteht, soll der Client die Objekte schnellst-moglich

erhalten. Dieser Anwendungsfall spielt bei allen vorangegangenen Anwendungsfallen

eine Rolle, soll hier nun aber isoliert getestet werden.

Beispiel:

Eine Anwendung, um Verlaufe des Aktienmarkts zu beobachten. Unerwartet konnen

die aktuellen Daten nicht an den Client gelangen, da die Verbindung abgebrochen

ist. Der Client versucht nun schnellstmoglich neu zu verbinden und die Verzogerung

so gering wie moglich zu halten, sodass veraltete Informationen nicht zu Fehlern

fuhren.

Der Client soll:

• nach Verbindungsabbruch unmittelbar eine neue Verbindung aufbauen

• Daten vom Server erhalten

Das System soll:

• Objekte an den Client senden

15


FrageObjekte an

Stelle neueVerbin-dung her


Client Server


3.2 Nicht-funktionale Anforderungen

Die nicht-funktionalen Anforderungen definieren globale Anforderungen, die es an

die Test-Applikation gibt. Sie spielen wahrend der Anwendungsentwicklung eine

kritische Rolle und haben großen Einfluss auf die Wahl des Designs und der gesamten

Architektur der Implementierung [22].

3.2.1 Anpassbarkeit

Eine Voraussetzung bei der Entwicklung des Systems ist die leichte Anpassbarkeit.

Diese bezieht sich hierbei auf eine einfache Anpassbarkeit von Testfallen, welche

mehrmals mit nur leicht abgeanderten Parametern ausgefuhrt werden mussen, um

das Verhalten der Metriken zu betrachten. Fur diese geringen Anpassungen sollte

kein bedeutender Aufwand betrieben werden mussen, um die Entwicklungszeit ge-

ring zu halten.

3.2.2 Erweiterbarkeit

Der Anwender muss die Moglichkeit haben, die Anwendungs- und Testfalle zu erwei-

tern. Dabei ist von Bedeutung, dass nur geringe Anpassungen in der Implementation

vorgenommen werden mussen und die Struktur des Systems von Erweiterungen der

Testfalle nicht beeinflusst wird.

3.2.3 Benutzerfreundlichkeit

Zur Ausfuhrung eines Testfalls sollen vom Anwender nur minimale Konfigurationen

notig sein, beispielsweise die Auswahl des Testfalls. Anpassungen an der Implemen-

tierung sollen nicht benotigt werden, da dies nur auf Kosten der Nutzerfreundlichkeit

moglich ist. Wahrend der Ausfuhrung des Tests soll eine Interaktion zwischen dem

Anwender und dem System ebenfalls nicht notig sein; der Test soll nach Start selbst-

standig ausgefuhrt werden und schließlich terminieren.

16


3.2.4 Reproduzierbarkeit

Um die Tests von mehreren Anwendern auf unterschiedlichen Geraten und ge-

gebenenfalls Betriebssystemen lokal auszufuhren, ist es wichtig, dass das System

unabhangig von Gerat, Betriebssystem und Konfigurationen auf dem Gerat ist.

Die Testfalle sollen jederzeit und auf unterschiedlichen Geraten ausgefuhrt werden

konnen.

17

Implementierung

In diesem Kapitel wird beschrieben, wie die in [1.1] erwahnte Anwendung imple-

mentiert wird. Zunachst soll hierfur eine Basis-Applikation erstellt werden, die die

Grundfunktionalitaten der Kommunikation mit HTTP/2, WebSockets und Rab-

bitMQ aufweist. Diese Applikation bildet die Basis, auf derer die individuellen An-

wendungsfalle implementiert werden. Die Implementierungen der Anwendungsfalle

im Test-System und die erstellten Testszenarien in JMeter mussen hierfur einander

angepasst werden. Nachdem das Test-System vollstandig ist, werden Docker Images

erstellt und diese in Containern gestartet. Die Ausfuhrung der Messungen wird in

der letzten Sektion dieses Kapitels erlautert.

4.1 Basis-Applikation

Dieser Teil der Anwendung bietet die Grundstruktur mit den technologieabhangigen

Grundfunktionalitaten zur Kommunikation mit HTTP/2, WebSockets und des Mes-

sage Brokers RabbitMQ. In den folgenden Unterkapiteln wird erklart, aus wel-

chen Grunden die genannten Technologien ausgewahlt wurden, welche Funktiona-

litaten in der Basis-Applikation implementiert werden sollen und wie dies umgesetzt

wird.

Die Basis-Server-Applikation wird in Java mit dem Framework Spring und der Er-

weiterung Spring Boot in Release 2.3.4 programmiert. Das Java Framework wird

bei mgm technology partners serverseitig standardmaßig genutzt und ist damit fur

diese Abschlussarbeit im Unternehmenskontext die logische Wahl.

4.1.1 HTTP/2

HTTP wird seit 1990 nach wie vor im World Wide Web als Protokoll zum Da-

tenaustausch zwischen Client und Server genutzt [8]. Nahezu jede Website nutzt

das Request/Response-Protokoll, was die Relevanz fur einen Vergleich mit anderen

Technologien oder Protokollen unterstreicht.

Es wurde entschieden, lediglich HTTP/2 und nicht HTTP/1.1 in den Vergleich

aufzunehmen. HTTP/1.1 wird zunehmend durch HTTP/2 ersetzt [23].

18

4. Implementierung

Anforderungen

Die Anwendung soll uber HTTP-Endpunkte HTTP/2 Requests erhalten und uber

die HTTP/2-Verbindung unmittelbar auf den Request antworten.

Entwicklung

HTTP/2 wurde zur Nutzung fur HTTP und HTTP Secure (HTTPS) definiert. Die

zu den popularsten zahlenden Browserimplementierungen, wie beispielsweise Chro-

me, Firefox und Edge, unterstutzen HTTP/2 jedoch nur, wenn die Verbindung uber

Transport Layer Security (TLS) stattfindet. Aufgrund dessen muss zunachst HTTPS

konfiguriert werden.

Nach Generierung eines SSL Zertifikats werden folgende Attribute in der Datei

application.yml konfiguriert:

• server.http2.enabled=true

• server.ssl.key-alias=[key-alias]

• server.ssl.key-store=[key-store]

• server.ssl.key-store-type=[key-store-type]

• server.ssl.key-password=[key-password]

Jetzt konnen in @Controller-Klassen Endpunkte erstellt werden, die auf Requests

zu den spezifizierten Pfaden antworten.

1 @Contro l ler

2 pub l i c c l a s s HTTP2Controller {3

4 @GetMapping ( value = ”/” )

5 @ResponseBody

6 pub l i c S t r ing ge tS impleSt r ing ( ) {7 return ”Das i s t d i e Antwort a l s S t r ing ” ;

8 }9 }

Quellcode 4.1: HTTP-Endpunkt fur Pfad /”bei Request mit GET-Methode

4.1.2 WebSocket

Nach der Standardisierung des WebSocket-Protokolls im Jahre 2011 wurden Web-

Sockets schnell von jedem modernen Browser unterstutzt und haben sich bei Echtzeit-

Anwendungen fur viele als erste Wahl durchgesetzt. Da der Request/Response Over-

head wegfallt, sollte dieses Protokoll effizienter als HTTP/2 sein. Die vermeintlich

gute Performance von WebSockets wird deshalb fur diverse Anwendungsfalle mit

den anderen Technologien verglichen.

19

4. Implementierung

Anforderungen

Die Anwendung soll WebSocket-Verbindungen mit Clients annehmen konnen und

imstande sein, Nachrichten uber die WebSocket-Verbindung zu erhalten und zu ver-

senden. Das Erhalten von Nachrichten soll uber STOMP-Destinations in einem Con-

troller geschehen.

Entwicklung

Da eine WebSocket-Verbindung uber eine HTTP/HTTPS-Verbindung mit einem

Upgrade-Header etabliert wird und die Anwendung fur HTTPS konfiguriert wurde,

nutzt der WebSocket in der Implementierung WebSocket Secure (wss).

Als Erweiterung zum WebSocket-Protokoll wird das Simple Text Oriented Messa-

ging Protocol (STOMP) genutzt, bei dem bestimmte Destinations abonniert werden.

Hierfur muss in der WebSocket @Configuration-Klasse, wie in [4.2] der Message

Broker konfiguriert und ein STOMP-Endpunkt registriert werden.

1 @Configuration

2 @EnableWebSocketMessageBroker

3 pub l i c c l a s s WebSocketConfig extends . . . implements . . . {4

5 @Override

6 pub l i c void reg i s terStompEndpoints ( StompEndpointRegistry r e g i s t r y )

{7 r e g i s t r y . addEndpoint ( ”/mySocket” ) . s e tAl lowedOr ig ins ( ”∗” ) ;8 }9

10 @Override

11 pub l i c void conf igureMessageBroker ( MessageBrokerRegistry c on f i g ) {12 c on f i g . enableSimpleBroker ( ”/ top i c /” ) ;

13 c on f i g . s e tApp l i c a t i o nDe s t i n a t i onP r e f i x e s ( ”/app” ) ;

14 }15 }

Quellcode 4.2: Konfiguration eines WebSockets mit STOMP

In einem Controller werden Nachrichten - ahnlich zum HTTP/2-Controller - uber

Destinations, spezifiziert in @MessageMapping(/..."), entgegengenommen und ver-

arbeitet. Uber die Annotation @SendTo(/topic/...") oder mit einer Instanz der

SimpMessageSendingOperations werden Nachrichten an Clients gesendet.

Die Frame-Size des WebSockets wird nicht verandert und hat einen Wert von 8196

Bytes.

4.1.3 RabbitMQ

Message Queues bieten eine asynchrone Kommunikation und die Option zur Umset-

zung von Echtzeit-Anwendungen. Damit bieten sie eine Alternative zu WebSockets,

konnen aber auch das Request/Response Muster simulieren und anstelle von HTT-

P/2 implementiert werden. Weiterhin bieten Message Queues gegenuber den beiden

20

4. Implementierung

Alternativen Vorteile [siehe 2.4], die jedoch moglicherweise auch negative Einflusse

auf die Performance haben konnen. Ein Vergleich mit HTTP/2 und WebSockets soll

zeigen, ob eine Message Queue eine gute Option ist, wenn Performance von hoher

Relevanz ist.

RabbitMQ dient stellvertretend fur Message Broker, die das AMQP-Protokoll imple-

mentieren. Darunter zahlen auch StormMQ und Apache ActiveMQ. RabbitMQ zahlt

unter open source Message Brokern zu den popularsten und ist auch im Technologie-

Stack von namhaften Unternehmen, wie der Deutschen Borse, und Goldman Sachs

[24], zu finden. RabbitMQ stellt damit einen guten Stellvertreter fur Message Broker

mit AMQP Implementierung dar.

Anforderungen

Die Anwendung soll notwendige User, Exchanges, Queues und Bindings definieren

und Nachrichten mit einem Producer uber eine Exchange an bestimmte Queues

senden. Ein Consumer soll sich mit einer definierten Queue verbinden und dort

eingehende Nachrichten konsumieren.

Entwicklung

Zunachst mussen die gewunschten User, Exchanges, Queues und Bindings definiert

werden. In einer Datei namens definitions.json werden diese Konfigurationen im

JSON-Format durchgefuhrt. Bei Start der Applikation werden die Definitionen in

RabbitMQ importiert.

Um die definierten Objekte in der Spring Boot Anwendung zu nutzen, werden die

benotigten Exchanges, Queues und Bindings in einer @Configuration Klasse fur

den Message Broker definiert und als @Beans annotiert.

Zur Authentifizierung eines Producers/Consumers bei RabbitMQ und zur Kommu-

nikation zum gewunschten Port werden diese Attribute in der application.yml-

Datei konfiguriert.

In [4.3] wird eine Direct-Exchange namens myExchangeName konfiguriert, die die

Parameter durable und autoDelete mit false deklariert. Es wird ebenfalls eine

Queue namens myQueueName konfiguriert, die den Wert false fur den Parameter

durable ubergibt. Die beiden Komponenten werden uber die Konfiguration eines

Bindings mit einem Routing-Key verbunden.

Uber die Bean der Exchange, eines Routing-Keys und der Instanz einer RabbitTem-

plate sendet ein Producer Nachrichten an die gewunschte Exchange.

Eine mit @RabbitListener(queues=[queueName]) annotierte Methode eines Con-

sumers erstellt die Verbindung mit der genannten Queue, um dort verfugbare Nach-

richten zu konsumieren.

21

4. Implementierung

1 @Bean2 pub l i c DirectExchange exchange ( ) {3 return new DirectExchange ( ”myExchangeName” , f a l s e , f a l s e ) ;4 }5 @Bean6 pub l i c Queue queue ( ) {7 return new Queue ( ”myQueueName” , f a l s e ) ;8 }9 @Bean

10 pub l i c Binding bindQueueToExchange ( @Qua l i f i e r ( ”queue” ) Queue queue ,DirectExchange exchange ) {

11 returnBindingBui lder . bind ( queue ) . to ( exchange ) . with ( ”myRoutingKey” ) ;

12 }

Quellcode 4.3: Konfiguration einer DirectExchange und einer Queue, die uber einBinding mit Routing-Key verbunden sind

4.2 Umsetzung der Anwendungsfalle

In den folgenden Unterkapiteln [4.2.1 - 4.2.5] wird beschrieben, wie die individuellen

Anwendungsfalle mit der Spring Boot-Anwendung und Apache JMeter umgesetzt

werden. Hierbei geht es darum, nachzuvollziehen, wie die Tests ablaufen und die

Testergebnisse zustande kommen. Die individuelle Umsetzung der Anwendungsfalle

basiert auf der entwickelten Basis-Applikation. Die entsprechende Client/Server Ar-

chitektur mit den Komponenten des Clients, des Servers und des Message Brokers

ist in Grafik [4.1] dargestellt. Diese Architektur bildet die Basis zur folgenden Um-

setzung.

Abbildung 4.1: Client/Server Architektur auf deren Basis die Anwendungsfalle im-plementiert werden

22

4. Implementierung

4.2.1 Anfrage unabhangiger Objekte

[Anforderungen siehe 3.1.1]

HTTP/2

In diesem Anwendungsfall sendet der JMeter-Client GET-Requests, gemaß dem Re-

quest/Response Muster, an den Server. Die Anzahl der Requests entspricht der An-

zahl der benotigten Objekte. Da die Objekte unabhangig voneinander sind, konnen

alle Requests Multiplexing verwenden.

Der Java-Server besitzt den entsprechenden HTTP-Endpunkt und antwortet unmit-

telbar mit einem String der gewunschten Große.

WebSocket

Der Anwendungsfall entspricht zwar prinzipiell dem Request/Response-Muster, der

WebSocket kann aber trotzdem von der Eigenschaft der Asynchronitat Gebrauch

machen. Es wird nicht jedes Objekt einzeln angefragt, sondern uber eine bestehende

WebSocket-Verbindung vom Client eine Nachricht gesendet, die uber die entspre-

chenden STOMP-Destinations das Versenden aller benotigten Objekte vom Server

an den Client veranlasst. Der Client liest somit nach Senden der Initialnachricht

lediglich alle ankommenden Objekte ein.

Der Server besitzt die genannte STOMP-Destination und sendet bei Eingang einer

Nachricht sofort die gewunschten Objekte uber die WebSocket-Verbindung an einen

anderen Endpunkt, der vom Client abonniert wird.

RabbitMQ

Die Message Queue verfahrt nach einem ahnlichen Prinzip wie der WebSocket. Der

JMeter-Client sendet durch einen Producer eine Nachricht uber eine Exchange an

eine Queue. Der Server besitzt einen Consumer, der auf Nachrichten in dieser Queue

wartet. Bei Erhalt der Nachricht wird sofort die gewunschte Anzahl an Objekten in

eine weitere Queue gesendet. Diese Queue wird wiederum von einem Consumer des

Clients abonniert, welcher die Objekte in Reihenfolge verarbeitet.

4.2.2 Informationsabhangigkeit


HTTP/2

Die Umsetzung dieses Anwendungsfalls ist analog zu dem Vorangegangenen, mit

dem Unterschied, dass Multiplexing nur bei einem Anteil der Requests stattfin-

den darf. Bei Anfragen an Objekte, die eine Abhangigkeit anderer Objekte sind,

muss vollstandig auf die Response gewartet werden, bevor das abhangige Objekt

angefragt wird. Somit gibt es einen hoheren Grad an Synchronitat in dem Anwen-

dungsfall.

23

4. Implementierung

WebSocket

Der Client sendet zunachst uber die WebSocket-Verbindung eine Nachricht an den

Server. Der Server sendet daraufhin alle Objekte an den Client, welche von keinem

anderen Objekt abhangig sind. Bei Eingang dieser Objekte am Client wird fur je-

des Objekt, das eine Abhangigkeit fur ein anderes Objekt besitzt, dieses uber eine

weitere Nachricht an den Server angefragt.

Der Server benotigt hierfur lediglich die entsprechenden STOMP-Destinations und

sendet die gewunschten Daten uber eine WebSocket-Verbindung an den Client.

RabbitMQ

Bei RabbitMQ wird wie beim WebSocket agiert. Die Nachrichten werden jedoch

nicht direkt zwischen Client und Server ausgetauscht, sondern dazwischen in der

Message Queue abgelegt. Da der Server nur einen Consumer besitzt, wird bei Erhalt

der Nachricht auf Grundlage des Nachrichten-Bodys entschieden, welche Objekte

versandt werden.

4.2.3 Aktualisierende Daten


HTTP/2

Da dieser Anwendungsfall nicht dem Request/Response-Muster entspricht, wird

hierfur HTTP/2 Long Polling verwendet. Der JMeter-Client sendet einen Long Pol-

ling Request mit großem Timeout an den Server. Der Server halt an dem Request

fest, bis die gewunschte Information verfugbar ist.

Ein weiterer, unabhangiger JMeter-Client sendet in einem festgelegten Intervall die

Informationen uber einen HTTP POST-Request an den Server. Sobald der Request

den Server erreicht, gibt dieser dem Long Polling Request das Signal, dass die Infor-

mation verfugbar ist. Der Long Polling JMeter-Client erhalt nun die Response auf

den Request.

WebSocket

Der JMeter Client erstellt eine WebSocket-Verbindung mit dem Server, abonniert

eine STOMP-Destination und wartet auf ankommende Nachrichten.

Ein weiterer JMeter-Client sendet in einem festgelegten Intervall die Informationen

uber einen HTTP POST-Request an den Server. Sobald der Request den Server

erreicht, leitet dieser die Informationen unmittelbar an den WebSocket-Client uber

die STOMP-Destination weiter.

RabbitMQ

Analog zur Umsetzung des WebSockets wird der Anwendungsfall mit RabbitMQ um-

gesetzt. Der JMeter-Client besitzt einen Consumer, der eine Message Queue abon-

niert hat und auf verfugbare Nachrichten wartet.

24

4. Implementierung

Parallel sendet ein weiterer JMeter-Client in einem festgelegten Intervall die Infor-

mationen uber einen HTTP POST-Request an den Server. Sobald der Request den

Server erreicht, leitet dieser die Informationen unmittelbar uber eine Exchange an

die Queue weiter, die vom JMeter-Client abonniert ist.

4.2.4 Mehrere Clients


HTTP/2

Dieser Anwendungsfall ist eine Erweiterung des Vorangegangenen und verhalt sich

demnach sehr ahnlich. Es gibt einen JMeter-Client, der in einem festgelegten Inter-

vall die zu verbreitenden Informationen uber einen HTTP POST-Request an den

Server sendet. Parallel gibt es weitere JMeter-Clients, die mit dem Server uber Long

Polling Requests verbunden sind. Bei Eingang der Informationen am Server erken-

nen die Long Polling Requests die Verfugbarkeit der Daten und die Clients erhalten

die Informationen als Response.

WebSocket

Fur den WebSocket wurde die Umsetzung dieses Anwendungsfalls ebenfalls ahnlich

zum Vorangegangenen gestaltet. Der POST-Request stellende Client und das Ver-

halten des Servers sind gleich. Nun gibt es jedoch eine Anzahl von JMeter-Clients,

die uber WebSocket-Verbindungen mit dem Server verbunden sind und die STOMP-

Destination fur den Broadcast abonniert haben. Somit erhalten alle diese Clients die

Daten.

RabbitMQ

Wieder gibt es einen Client, der in einem festgelegten Intervall die zu verbreitenden

Daten uber einen HTTP POST-Request an den Server sendet. Zudem gibt es eine

Anzahl weiterer JMeter-Clients, die die Daten erhalten sollen. Um zu ermoglichen,

dass der Consumer in jedem dieser Clients die Informationen erhalt, ist es notwendig,

dass jeder Client eine eigene Message Queue im Message Broker hat, welche von dem

entsprechenden Consumer abonniert ist. In den bisherigen Anwendungsfallen wur-

den stets Direct Exchanges verwendet. Nun wird eine Fanout Exchange verwendet,

die unabhangig von Routing-Keys die Nachrichten an alle Queues weiterleitet, die

uber ein Binding verbunden sind. Der Server leitet bei Eingang des HTTP POST-

Requests die Informationen unmittelbar an die Fanout Exchange weiter.

25

4. Implementierung

4.2.5 Neu-Verbindung


HTTP/2

Dieser Anwendungsfall kann mit HTTP/2 nicht umgesetzt werden, da HTTP ein

zustandsloses Protokoll ist. Daher konnen Verbindungen von anderen Clients oder

dem Server nicht einfach abgebrochen werden.

WebSocket

Ein JMeter-Client stellt eine WebSocket-Verbindung mit dem Server her und abon-

niert eine STOMP-Destination. Falls die Verbindung abbricht, wird unmittelbar eine

neue WebSocket-Verbindung hergestellt und die Destination abonniert.

Der Java-Server registriert jede neue WebSocket-Verbindung in einem Session Hand-

ler. In einem festgelegten Intervall bricht der Session Handler alle bekannten WebSocket-

Verbindungen ab. Der betroffene Client erhalt daraufhin die Benachrichtigung, dass

die Verbindung abgebrochen ist und stellt eine neue Verbindung her.

RabbitMQ

Ein JMeter-Client besitzt einen RabbitMQ Consumer, der mit einer Message Queue

verbunden ist und bei Abbruch der Verbindung sofort eine neue Verbindung zu

dieser Message Queue aufbaut.

Die Verbindung des Clients zur Message Queue kann extern abgebrochen werden,

indem ein HTTP DELETE-Request mit dem Verbindungsnamen der abzubrechen-

den Verbindung an die RabbitMQ API getatigt wird. Hierfur muss zunachst der

zufallig generierte Verbindungsname herausgefunden werden. Dies ist durch einen

weiteren API Aufruf an RabbitMQ moglich. Nach Verbindungsabbruch erhalt der

betroffene Client eine Benachrichtigung uber den Verbindungsabbruch.

Die Operationen zum Herausfinden der Verbindungsnamen und zum Abbrechen der

Verbindungen werden in einem festgelegten, periodischen Intervall durchgefuhrt.

4.3 Messung

Dieser Abschnitt diskutiert die Testumgebung sowie die Rolle von Docker und Li-

mitierungen. Zunachst wird beschrieben wie in den einzelnen Bereichen entschieden

wurde und argumentiert, aus welchen Grunden die Entscheidungen getroffen wur-

den. Limitierungen beschreiben potenzielle Probleme und Fehlerquellen in der Te-

stumgebung. Informationen zur Durchfuhrung der Tests sind in [A.1] zu finden.

26

4. Implementierung

4.3.1 Umgebung

Bei der Durchfuhrung der Tests gibt es funf Moglichkeiten die Hardware der Te-

stumgebung zu gestalten:

1. Clients, Server und RabbitMQ laufen auf derselben Hardware ohne Isolierung

2. Clients, Server und RabbitMQ laufen als isolierte Prozesse auf derselben Hard-

ware

3. Clients, Server und RabbitMQ laufen als isolierte virtuelle Maschinen auf der-

selben Hardware

4. Clients, Server und RabbitMQ laufen auf eigenen physischen Maschinen in

demselben Netzwerk

5. Clients, Server und RabbitMQ laufen auf eigenen, isolierten Online Servern

eines Cloud-Anbieters

Fur Performance Tests ist es wichtig, dass die Komponenten isoliert voneinander

sind, nicht von anderen Prozessen wissen und diese vor allem nicht beeintrachtigen.

Damit bleiben Option 2 bis Option 5 ubrig. In der Anforderungsanalyse lautete eine

der nicht-funktionalen Anforderungen [siehe 3.2] Reproduzierbarkeit. Eine einfache

Reproduzierbarkeit ist nur gegeben, wenn die Tests auf einer einzigen Hardware

durchgefuhrt werden konnen, Option 4 und 5 scheiden daher aus. Fur Option 5

ist ebenfalls anzumerken, dass viele online Server-Instanzen physische Hardware-

ressourcen untereinander teilen. Von den beiden verbleibenden Optionen 2 und 3

fallt die Entscheidung auf Option 2, da bei der Virtualisierung ein gewisser Over-

head anfallt, der die CPU verlangsamt. Das leichtgewichtige Containerisieren zur

Prozessisolierung bei Option 2 ist daher die bessere Wahl.

Potenzielle Limitierungen durch die Wahl von Option 2 werden in [4.3.3] disku-

tiert.

Die verwendete Hardware hat folgende Spezifikation:

Element Wert

Modell Lenovo Thinkpad T470sBetriebssystem Microsoft Windows 10 Enterprise 10.0.18362Prozessor Dual Core Intel Core i7-7500U 2.70 GHzRAM 24.0 GB

Tabelle 4.1: Spezifikation der Hardware

4.3.2 Docker

Fur die Containerisierung und damit die Isolierung der Prozesse wird Docker ge-

nutzt. Ein weiterer wichtiger Grund fur die Nutzung von Docker ist die Reprodu-

zierbarkeit, die dadurch gegeben ist, dass die Anwendungen unabhangig vom System

gestartet werden konnen.

27

4. Implementierung

Die Spring Boot-Serveranwendung, die JMeter-Clients und RabbitMQ sollen in

Docker-Containern uber eine docker-compose.yml Datei gestartet werden. Hierfur

werden die Docker Images fur diese drei Komponenten benotigt.

Die Spring Boot-Anwendung wird auf Basis des offiziellen Images openjdk:11 er-

stellt. Fur RabbitMQ wird das offizielle Image rabbitmq:3-management-alpine

verwendet. Das Docker Image von JMeter benotigt vier Plugins. Es konnte kein

offentliches Docker Image mit allen benotigten Plugins gefunden werden, weshalb

auf Grundlage des JMeter-Images von egaillardon [25] ein eigenes Dockerfile erstellt

wurde.

Die Images werden in einer erstellten docker-compose Datei referenziert. Zusatzlich

werden fur jede der drei Komponenten die benotigten Konfigurationen getroffen.

Genauere Angaben zur Konfiguration in docker-compose.yml sind in [A.1] zu fin-

den.

4.3.3 Limitierungen

Die getroffenen Entscheidungen bezuglich der Testumgebung sind nicht fehlerfrei

und bringen gewisse Einschrankungen mit sich. Die Limitierungen werden in diesem

Unterkapitel diskutiert.

Geteilte Ressourcen

In [4.3.1] wurde entschieden, die Tests lokal auf einer einzigen Hardware auszufuhren.

Da somit Clients und Server parallel die Systemressourcen nutzen mussen, ist es nur

schwer abzuschatzen, wie viele Ressourcen von welcher Komponente beansprucht

werden. Das kann bei Performance-Tests zu Messungenauigkeiten fuhren.

Virtualisierung

Die Tests werden mit Docker auf einem Windows-Betriebssystem durchgefuhrt,

wofur das Werkzeug Docker Desktop for Windows genutzt wird. Ein Grund zur

Nutzung von Docker ist die Leichtgewichtigkeit gegenuber virtuellen Maschinen, die

einen Virtualisierungsoverhead haben. Docker Desktop for Windows nutzt jedoch

die Technologie der Engine Hyper-V. Hyper-V ist eine Virtualisierungssoftware, die

benotigt wird, um einen Linux Kernel zu simulieren. Dies lasst vermuten, dass trotz

des angestrebten Vermeidens einer virtuellen Maschine durch Docker ein Overhead

existiert und die Performance beeintrachtigt werden kann.

Nur eine Softwareplattform

Sowohl der Server als auch JMeter sind Java-Anwendungen. Alles Tests werden

ausschließlich in dieser Kombination durchgefuhrt und Resultate konnen auf anderen

Plattformen wie beispielsweise node.js potenziell abweichen.

28

Auswertung

In diesem Kapitel werden die Testergebnisse ausgewertet. Jeder Anwendungsfall

wird individuell betrachtet und die wichtigsten Eigenschaften beschrieben. Dazu

gehort die Definition der Metrik, die fur den Vergleich herangezogen wird und die

Benennung aller Parameter, die fur den Test elementar sind. Jeder einzelne Test wird

dreimal ausgefuhrt. Aus den Messergebnissen der drei Durchlaufe wird das arith-

metische Mittel berechnet. Fur die Anwendungsfalle [3.1.1] bis [3.1.4] fließen die

anfanglichen Verbindungszeiten der jeweiligen Technologie nicht in die Berechnung

mit ein. Fur jeden Anwendungsfall werden die Resultate prasentiert und beschrie-

ben.

5.1 Anfrage unabhangiger Objekte

Die Vergleichsmetrik dieses Anwendungsfalls ist die Zeit vom Senden des ersten

Requests, bis zum vollstandigen Erhalt des letzten Objekts.

Fur diesen Anwendungsfall wird die Vergleichsmetrik fur zwei unterschiedliche Pa-

rameter berechnet. Zunachst ist die Anzahl der benotigten Objekte der variierende

Parameter. In den zweiten Tests wird die Zielmetrik in Abhangigkeit von der Große

eines einzelnen Objekts berechnet.

In den ersten Tests ist die Objektgroße auf 1 KB festgelegt. Die Objektanzahl hat

einen minimalen Wert von 1 und einen maximalen Wert von 1000. In diesem Be-

reich werden 12 Tests ausgefuhrt. Fur jeden Testdurchlauf wird die Vergleichsmetrik

berechnet, indem der Zeitpunkt des Eingangs des letzten Objekts beim Client von

dem Zeitpunkt des Sendens der ersten Anfrage subtrahiert wird.

29

5. Auswertung

1 100 200 300 400 500 600 700 800 900 1,0000

200

400

600

800

1,000

1,200

1,400

1,600

1,800

2,000

Anzahl der benotigten Objekte

Lat

enz

[in

ms]

HTTP/2WebSocketRabbitMQ

Abbildung 5.1: Latenzen, abhangig von der Objektanzahl

In Abbildung [5.1] kann man erkennen, dass die Verzogerung bei allen drei Technolo-

gien bei unter 50 ms fur das Anfragen und Erhalten eines einzigen Objekts liegt. Die

Verzogerung bei HTTP/2 steigt bis zu einer Anzahl von 100 benotigten Objekten

schnell an und wachst von dort relativ gleichmaßig mit einer Steigung von 100 ms

bis 150 ms pro 100 zusatzlicher Objekte. Die maximale Verzogerung liegt bei 900

Objekten und 1589 ms.

Beim WebSocket ist ein gleichmaßigerer Verlauf zu erkennen. Im Vergleich zu HTT-

P/2 gibt es anfangs keine starken Schwankungen und Verzogerungen bleiben kon-

stant bei Werten, die weniger als die Halfte der Vergleichswerte von HTTP/2 betra-

gen. Die viel kleinere Latenz ist unter anderem damit zu erklaren, dass der Server

nach der ersten Anfrage vom Client alle Objekte ohne weitere Anfragen, entge-

gen des Request/Response Musters, an den Client senden kann. Ab einer Anzahl

von mehr als 500 Objekten, die vom Client verarbeitet werden mussen, bricht die

WebSocket-Verbindung ab und zukunftige Daten gehen verloren.

RabbitMQ hat ahnlich zum WebSocket einen gleichmaßigen, aber flachen, Anstieg

von durchschnittlich ungefahr 75 ms pro 100 zusatzlicher Objekte. Die Verzogerung

liegt knapp uber der des WebSockets, jedoch deutlich unter der von HTTP/2. Die

maximale Verzogerung liegt bei 1000 Objekten und 772 ms. Im Gegensatz zum

WebSocket gehen keine Informationen verloren.

In den zweiten Tests ist die Anzahl der Objekte auf 10 festgelegt. Die Große eines

einzelnen Objekts variiert von minimal 1 KB bis zu maximal 50 KB. In diesem

Bereich werden 6 Tests durchgefuhrt. Die Berechnung der Vergleichsmetrik verlauft

30

5. Auswertung

analog zu den ersten Tests.

1 5 10 15 20 25 30 35 40 45 500

20

40

60

80

100

120

140

160

180

200

Große eines einzelnen Objekts [in KB]

Lat

enz

[in

ms]


Abbildung 5.2: Latenzen, abhangig von der Objektgroße

In Abbildung [5.2] ist festzustellen, dass sich die Technologien im Bereich 1 KB bis

50 KB sehr ahnlich zueinander verhalten. HTTP/2 hat die besten Ergebnisse mit

einer maximalen Verzogerung von 113 ms.

Beim WebSocket sind die großten Verzogerungen zu erkennen. Trotz der hoheren

Latenz weist die Steigung einen gleichmaßigen Verlauf von 63 ms zu 163 ms auf. Die

erhohte Latenz kann mit der definierten Frame Size zusammenhangen. Diese betragt

in der vorliegenden Implementierung standardmaßig 8196 Bytes. Wird ein Objekt

versendet, welches diesen Wert uberschreitet, mussen die Daten auf mehrere Nach-

richten aufgeteilt und somit insgesamt mehr Nachrichten gesendet werden.

Der Verlauf von RabbitMQ liegt ungefahr in der Mitte zwischen HTTP/2 und dem

WebSocket. Die maximale Verzogerung in dem getesteten Bereich ist bei 50 KB

und 139 ms. Damit liegt dieser Hochstwert zwischen dem des WebSockets und von

HTTP/2.

5.2 Informationsabhangigkeit

Die Vergleichsmetrik dieses Anwendungsfalls ist die Zeit vom Senden des ersten

Requests, bis zum vollstandigen Erhalt der letzten Daten beim Client.

31

5. Auswertung

Die zugrundeliegenden Parameter werden in Tabelle [5.1] genannt.

Parameter Wert

Objektanzahl 100Objektgroße 1 KBAnteil der Objekte, die von einem anderen abhangig sind variiert

Tabelle 5.1: Parameter fur Anwendungsfall 2

Der Anteil der Objekte, die von einem anderen abhangig sind, hat in den ersten Tests

einen Wert von 25 %. In den darauffolgenden Tests wird dieser Wert auf 50 % erhoht

und in letzten Tests ist jedes Objekt von dem zuvor angefragten Objekt abhangig.

Lediglich das erste Objekt hat keine Abhangigkeit, somit betragt der Prozentwert

99 %. Wie in Anwendungsfall 1, wird fur jeden Testdurchlauf die Vergleichsmetrik

berechnet, in dem der Zeitpunkt des Eingangs des letzten Objekts beim Client, von

dem Zeitpunkt des Sendens der ersten Anfrage subtrahiert wird.

0 25 50 75 990

100

200

300

400

500

600

700

800

900

1,000

Anteil der Objekte mit Abhangigkeit [in %]

Lat

enz

[in

ms]


Abbildung 5.3: Latenzen, abhangig von dem Anteil der Objekte mit Informations-abhangigkeit

In Abbildung [5.3] ist zu erkennen, dass HTTP/2 nicht bedeutend von dem va-

riierenden Anteil abhangiger Objekte beeinflusst wurde. Erwartet wurde, dass ei-

ne Erhohung des Anteils mit einer Erhohung der Latenz einhergeht, da HTTP/2

aufgrund von Multiplexing asynchrone Requests stellen kann. Die Erhohung der

Abhang-igkeit erhoht den Anteil der Requests, die synchronisiert sein mussen. Die-

se Tatsache scheint bei den festgelegten Parametern keinen großen Einfluss auf die

Resultate zu haben.

32

5. Auswertung

Der Verlauf des WebSockets zeigt eine stetig positive Steigung. Besonders auffallig

ist, dass ich die Latenz zwischen 0 % und 25 % mehr als verdoppelt, da nun

zusatzliche Anfragen getatigt werden mussen. Die maximale Verzogerung liegt mit

644 ms bei 99 % deutlich hoher als HTTP/2 und RabbitMQ.

RabbitMQ hat anfangs einen ahnlich starken Anstieg der Latenz wie der WebSocket,

was auch auf die Notwendigkeit zusatzlicher Anfragen zuruckzufuhren ist. Nach Er-

reichen der 25 %, flacht die Kurve jedoch stark ab und hat, wie HTTP/2, kaum

noch Schwankungen. Mit einer maximalen Verzogerung von 432 ms bei 99 % An-

teil von Objekten mit Abhangigkeit auf andere Objekte hat RabbitMQ die besten

Ergebnisse.

5.3 Aktualisierende Daten

Die Vergleichsmetrik dieses Anwendungsfalls ist die Latenz zwischen dem Senden

der Daten vom Client zum Server und dem vollstandigen Erhalt der Daten

bei dem anderen Client.


Parameter Wert

Datengroße 1 KBIntervall, in dem die Daten an den Server gesendet werden variiert


Das Intervall, in dem die Daten an den Server gesendet werden, hat anfangs einen

Wert von 10 Sekunden. Dieses Intervall wird stetig kleiner und hat schließlich einen

minimalen Wert von 0,05 Sekunden. Fur jeden Testdurchlauf wird ein Durchschnitts-

wert berechnet. Dieser setzt sich aus den ersten 18 Werten zusammen, die berechnet

werden, in dem der Zeitpunkt des Eingangs der Daten beim Client von dem Zeit-

punkt des Sendens des entsprechenden POST-Requests subtrahiert wird. Der ers-

te Wert wird von der Durchschnittswertberechnung ausgenommen, da dieser große

Schwankungen aufweist.

33

5. Auswertung

10 5 2.5 1.25 0.62 0.31 0.15 0.07 0.04

5

10

15

20

25

30

35

40

45

50

Intervall [logarithmisch in Sekunden]

Lat

enz

[in

ms]

Long PollingWebSocketRabbitMQ

Abbildung 5.4: Latenzen, abhangig von der Große des Intervalls, in dem sich Datenaktualisieren

Die Abbildung [5.4] zeigt fur den WebSocket und RabbitMQ einen sehr ahnlichen

Verlauf, bei Long Polling weicht dieser ab. Sowohl bei RabbitMQ, als auch dem

WebSocket ist die Latenz durch die Große des Intervalls nicht bedeutend beein-

flusst.

HTTP Long Polling hat bei jedem Intervall im Vergleich die großten Verzogerungen.

Auffallig ist die abrupte Steigung vom Intervall 0,5 Sekunden zu 0,1 Sekunden.

Ab dem Intervall von 0,1 Sekunden, erreichen zudem nicht mehr alle Daten den

Client. Bei 0,1 Sekunden konnten 45 % der HTTP/2 POST-Requests nicht am Server

verarbeitet werden. Bei einem Intervall von 0,05 Sekunden lag der Wert bei 52 %. Es

ist ebenfalls zu beachten, dass es nach Erhalt der Informationen beim Client einen

gewissen Zeitraum gibt, bis ein neuer Long Polling Request den Server erreicht. In

diesem Zeitraum kann ein Client potenzielle neue Daten nicht erhalten.

Die Latenz des WebSockets und von RabbitMQ unterscheiden sich in diesem An-

wendungsfall kaum. Aufgrund des Pub/Sub Systems gibt es bei diesen Technologien

keinen Zeitraum, in dem der Client nicht verfugbar ist. Fur diesen Anwendungsfall

sind die beiden Technologien gut ausgelegt und ermoglichen eine sehr gute Perfor-

mance.

34

5. Auswertung

5.4 Mehrere Clients

Die Vergleichsmetrik dieses Anwendungsfalls ist die Latenz zwischen dem Senden

der Daten vom Client zum Server und dem Moment, in dem der letzte

Client diese Daten vollstandig erhalten hat.


Parameter Wert

Datengroße 1 KBIntervall der HTTP POST-Requests 5 SekundenAnzahl weiterer Clients variiert


Die Anzahl der weiteren Clients betragt anfangs 1 und steigert sich uber insgesamt

11 Tests zu einem Wert von 100. Fur jeden Testdurchlauf wird ein Durchschnittswert

berechnet. Dieser setzt sich aus 12 Werten zusammen, die berechnet werden, indem

der Zeitpunkt des Eingangs der Daten beim letzten Client von dem Zeitpunkt des

Sendens des entsprechenden POST-Requests subtrahiert wird.

1 10 20 30 40 50 60 70 80 90 1000

50

100

150

200

250

300

Anzahl der Clients

Lat

enz

[in

ms]

Long PollingWebSocketRabbitMQ

Abbildung 5.5: Latenzen, abhangig von der Anzahl der Clients

In Abbildung [5.5] ist zu erkennen, dass alle Technologien mit dem Anstieg an Clients

auch einen Anstieg an Latenz aufweisen. HTTP/2 hat gesamtheitlich die großte

Steigung und ebenfalls den Verlauf mit den meisten Schwankungen. Die maximale

Latenz wird in dem gewahlten Bereich bei einer Anzahl von 100 Clients erreicht und

betragt 252 ms.

35

5. Auswertung

Der Verlauf der WebSockets ist im Vergleich flach und steigt nur leicht. Die anfang-

liche Latenz von 17 ms erreicht einen maximalen Wert von 40 ms. Damit weist der

WebSocket die mit Abstand besten Resultate auf und liegt im maximalen Wert 84

% unter dem von Long Polling.

Die Latenz bei RabbitMQ steigt gleichmaßig mit einer durchschnittlichen Steigung

von weniger als 8 ms pro 10 zusatzlicher Clients. Der Verlauf von RabbitMQ befindet

sich damit im Bereich von 1 bis 100 Clients stets zwischen Long Polling und dem

WebSocket. Der Hochstwert ist dabei aber noch deutlich unter dem von Long Polling

und betragt weniger als 50 % des Vergleichswerts.

5.5 Neu-Verbindung

Die Vergleichsmetrik dieses Anwendungsfalls ist die Zeit zwischen Verbindungs-

abbruch und vollstandiger Neu-Verbindung.

Die Verbindungsabbruche finden in einem Intervall von 10 Sekunden statt. Dieser

Abstand soll sicherstellen, dass es keinen Einfluss auf die Neu-Verbindungszeit gibt.

Fur jeden Testdurchlauf wird ein Durchschnittswert berechnet. Dieser setzt sich

aus 6 Werten zusammen, die jeweils berechnet werden, indem der Zeitpunkt des

erneuten Wartens auf verfugbare Nachrichten von dem Zeitpunkt des Eingangs der

Benachrichtigung eines Verbindungsabbruchs subtrahiert wird.

0 10 20 30 40 50 60 70 80 90 100 110

92

51

Zeit [in ms]

WebSocketRabbitMQ

Abbildung 5.6: Zeit zwischen einem Verbindungsabbruch und der erneuten Verbin-dungsherstellung

Mit 92 ms ist die Neu-Verbindungszeit des WebSockets deutlich hoher als die der

Message Queue. Der WebSocket nutzt das STOMP-Protokoll und muss daher nach

erfolgreicher Verbindung auch den gewunschten Endpunkt abonnieren, um in der

36

5. Auswertung

Lage zu sein, Nachrichten zu empfangen. Zusatzlich zu einer hoheren Zeit sind zudem

alle Nachrichten verloren, die in diesem Zeitraum den Client erreichen sollten.

Der Consumer fur RabbitMQ benotigt durchschnittlich nur 51 ms, um wieder mit

der Message Queue verbunden zu sein. Nachrichten, die wahrend der Abwesenheit an

diese Queue gesendet wurden, sind dort verblieben und konnen direkt vom Consumer

konsumiert werden.

37

Fazit

In diesem Kapitel wird auf Grundlage der Resultate zusammengefasst, wie gut die

Technologien im Vergleich, fur welche A12 Business-Anwendungen geeignet sind. Der

Aspekt der Performance ist hierbei elementar, weitere Faktoren die bei individuellen

Anwendungsfallen eine Rolle spielen, sowie der Entwicklungsaufwand, fließen jedoch

auch in die Bewertung ein.

6.1 HTTP/2

Der Entwicklungsaufwand zur Implementierung von HTTP/2 in einer Applikation

ist vergleichsweise gering. Es muss jedoch darauf geachtet werden, dass in moder-

nen Browsern eine Unterstutzung nur gegeben ist, wenn eine HTTPS-Verbindung

besteht. Insgesamt muss somit lediglich TLS eingerichtet und beliebige Endpunkte

erstellt werden. Zur Implementierung von Long Polling sind keine weiteren Konfi-

gurationen notig.

Die Verwendung von HTTP/2 ist eine gute Option, wenn Daten nach dem Re-

quest/Response Muster einzeln angefragt werden sollen. Insbesondere, wenn weni-

ge, große Objekte transferiert werden, performed HTTP/2 sehr gut und bietet im

Bereich von einer Objektgroße von 10 KB bis 50 KB eine durchschnittlich 22,4% ge-

ringere Ubertragungszeit als RabbitMQ. Im Vergleich mit dem WebSocket betragt

der Wert 32,2%.

Wenn viele Daten kleiner Große ubermittelt werden, oder sich Live-Daten in Inter-

vallen aktualisieren, uberzeugt HTTP/2 und Long Polling nicht. Hier gibt es durch

WebSockets und Message Queues deutlich bessere Alternativen.

6.2 WebSocket

Die Implementierung eines WebSockets mit STOMP ist fur einen Entwickler nur in

geringem Maße aufwendiger als HTTP/2. Da die Verbindung uber HTTP/HTTPS

initialisiert wird, ist diese Konfiguration notwendig. Die weitere benotigte Konfi-

guration, die sich auf die Registrierung der gewunschten STOMP-Endpunkte be-

schrankt, stellt kaum Mehraufwand dar. Bei WebSockets hat der Entwickler auf-

38

6. Fazit

grund der Eigenschaft der Zustandsbehaftung die Moglichkeit, Sessions zu verwal-

ten und damit Kontrolle uber die WebSocket-Verbindungen mit Clients zu erhalten.

Eine aufwendigere Implementierung ist somit moglich, aber nicht notig.

Der WebSocket bietet sehr gute Ergebnisse bezuglich der Performance bei der Uber-

mittlung von konstant aktualisierenden Daten. Das WebSocket-Protokoll hat hier

die geringste Latenz, die insbesondere bei A12 Business-Anwendungen mit einer

hoheren Anzahl von Clients im getesteten Bereich uberzeugt. Bei 100 Clients spart

der WebSocket durchschnittlich 63% Verzogerungszeit im Vergleich zu der Message

Queue. Im Vergleich zu HTTP Long Polling betragt der Wert sogar 84%. WebSockets

bieten im Vergleich eine besonders gute Performance, wenn die Nachrichtengroße

nicht die Frame-Size ubersteigt.

Das WebSocket Protokoll ist nicht dafur ausgelegt nach dem Request/Response

Muster Nachrichten zu ubermitteln, was sich auch in der Performance widerspiegelt.

Wenn es von großer Relevanz ist, dass Nachrichten niemals verloren gehen, sollten

WebSockets ohne Queue ebenfalls nicht verwendet werden. Nachrichten sind nicht

persistent und die Zeit zur Neu-Verbindung eines WebSockets mit STOMP ist fast

doppelt so groß wie die benotigte Zeit der Message Queue.

6.3 RabbitMQ

Die Implementierung des Message Brokers RabbitMQ ist deutlich aufwendiger als

die der WebSockets oder HTTP/2. Durch RabbitMQ wird eine gesamte, zusatzliche

Anwendung Teil der Verwaltung fur den Entwickler. Teil der Entwicklung ist das

Definieren aller gewunschten Komponenten, wie User, Exchanges, Queues und Bin-

dings, welche jeweils eigene Konfigurationen benotigen. Im Gegensatz zu HTTP/2

und WebSockets haben die meisten Message Broker jedoch den Vorteil, dass die

Lastverteilung nicht aufwendig implementiert werden muss, sondern bereits inte-

griert ist.

Fur das Senden vieler, unabhangiger Informationen, im getesteten Bereich von bis

zu 1000 Objekten, bietet RabbitMQ eine sehr gute Performance. Bei 1000 Objekten

benotigt die Message Queue weniger als 50% der Zeit von HTTP/2. Auch bei A12

Business-Anwendungen, die das Request/Response Muster bedingen, performed die

AMQP-Implementierung gut. Hierfur kann der einfach zu implementierende Remo-

te procedure call (RPC) genutzt werden [26]. Fur standig aktua-lisierende Daten ist

RabbitMQ ebenfalls sehr gut geeignet und bietet eine Latenz, die fur einen Client mit

dem WebSocket zu vergleichen ist. Mit einer steigenden Anzahl von Clients, steigt

jedoch auch die Abweichung zum WebSocket, liegt aber bei 100 Clients mehr als

50% unter den Resultaten von Long Polling und ist deshalb akzeptabel. Zusatzlich

sind Nachrichten persistent in der Queue und daher vor potenziellen Verbindungs-

abbruchen oder Uberlastungen geschutzt.

Die Message Queue liefert die besten Resultate bezuglich der Performance wenn die

Nachrichtengroße gering ist. In dem Bereich von 10 KB bis zu 50 KB kann RabbitMQ

39

6. Fazit

damit nicht mit den Resultaten von HTTP/2 mithalten und hat durchschnittlich

28% großere Verzogerungen. Fur diese A12 Business-Abwendungen gibt es somit

eine bessere Alternative fur moglichst geringe Latenzen.

40

Quellenverzeichnis

[1] David E. Steitz und Allen Kenitzer. NASA FINDS PROBLEMS IN EOS-

DIS FLIGHT OPERATIONS SOFTWARE DEVELOPMENT. 10. Apr. 1998.

url: https://www.nasa.gov/home/hqnews/1998/98-060.txt (besucht am

27. 09. 2020).

[2] Trade Delays Lead To Compensation — The Spokesman-Review. 31. Okt.

1997. url: https://www.spokesman.com/stories/1997/oct/31/trade-

delays-lead-to-compensation/ (besucht am 27. 09. 2020).

[3] “Client-Server Model”. In: 16 (2014), S. 57–71. issn: 22788727, 22780661. doi:

10.9790/0661- 16195771. url: http://www.iosrjournals.org/iosr-

jce/papers/Vol16-issue1/Version-9/J016195771.pdf.

[4] Øyvind Raasholm Tangen. “Real-Time Web with WebSocket”. In: (Mai 2015).

url: https://www.duo.uio.no/bitstream/handle/10852/44808/7/

tangen-master.pdf.

[5] Apache JMeter - Apache JMeter™. url: https://jmeter.apache.org/

index.html (besucht am 03. 09. 2020).

[6] Sai Matam und Jagdeep Jain. Pro Apache JMeter: Web Application Perfor-

mance Testing. Google-Books-ID: YJ4xDwAAQBAJ. Apress, Aug. 2017. isbn:

978-1-4842-2961-3.

[7] mgm: A 12. url: https://www.mgm-tp.com/produkte/a12/ (besucht am

17. 09. 2020).

[8] Jeffrey C. Mogul u. a. Hypertext Transfer Protocol – HTTP/1.1. url: https:

//tools.ietf.org/html/rfc2068 (besucht am 17. 09. 2020).

[9] Roy Fielding und Julian Reschke. Hypertext Transfer Protocol (HTTP/1.1):

Message Syntax and Routing. url: https://tools.ietf.org/html/rfc7230

(besucht am 17. 09. 2020).

[10] Mike Belshe, Martin Thomson und Roberto Peon. Hypertext Transfer Protocol

Version 2 (HTTP/2). url: https://tools.ietf.org/html/rfc7540#page-

4 (besucht am 17. 09. 2020).

41

6. QUELLENVERZEICHNIS

[11] Nagy Ramadan und Ihab Mohamed. “Impact of Implementing HTTP/2 in

Web Services”. In: International Journal of Computer Applications 147.9 (Aug.

2016), S. 27–32. issn: 09758887. doi: 10.5120/ijca2016911182. url: http:

//www.ijcaonline.org/archives/volume147/number9/darwish-2016-

ijca-911182.pdf (besucht am 17. 09. 2020).

[12] hjp: doc: RFC 6202: Known Issues and Best Practices for the Use of Long

Polling and Streaming in Bidirectional HTTP. url: https://www.hjp.at/

doc/rfc/rfc6202.html#sec_1 (besucht am 18. 09. 2020).

[13] hjp: doc: RFC 6455: The WebSocket Protocol. url: https://www.hjp.at/

doc/rfc/rfc6455.html#sec_1 (besucht am 21. 09. 2020).

[14] STOMP. url: https://stomp.github.io/stomp-specification-1.2.

html (besucht am 23. 10. 2020).

[15] Sanika Raje. “Performance Comparison of Message Queue Methods”. In: (Aug.

2019), S. 69. url: https://digitalscholarship.unlv.edu/cgi/viewcontent.

cgi?article=4749&context=thesesdissertations.

[16] Gregory Marsh u. a. “Scaling Advanced Message Queuing Protocol (AMQP)

Architecture with Broker Federation and InfiniBand”. In: (2008). url: ftp:

//ftp.cse.ohio-state.edu/pub/tech-report/2009/TR17.pdf.

[17] Andre Laszlo. “A Distributed Publish/Subscribe System built on a DHT Sub-

strate”. In: (2016), S. 86. url: https://odr.chalmers.se/bitstream/20.

500.12380/232548/1/232548.pdf.

[18] Andrew Silver. “Software simplified”. In: Nature News 546.7656 (Juni 2017).

Section: Toolbox, S. 173. doi: 10.1038/546173a. url: http://www.nature.

com/news/software-simplified-1.22059 (besucht am 19. 10. 2020).

[19] Babak Bashari Rad, Harrison Bhatti und Mohammad Ahmadi. “An Intro-

duction to Docker and Analysis of its Performance”. In: IJCSNS Interna-

tional Journal of Computer Science and Network Security 173 (Marz 2017),

S. 8. url: https://www.researchgate.net/publication/318816158_An_

Introduction_to_Docker_and_Analysis_of_its_Performance.

[20] James Turnbull. The Docker Book: Containerization Is the New Virtualization.

Google-Books-ID: 4xQKBAAAQBAJ. James Turnbull, Juli 2014. isbn: 978-

0-9888202-0-3.

[21] Daniel Nust u. a. “Ten Simple Rules for Writing Dockerfiles for Reproducible

Data Science”. In: (Apr. 2020). Publisher: OSF Preprints. doi: 10.31219/

osf.io/fsd7t. url: https://osf.io/fsd7t/ (besucht am 24. 09. 2020).

[22] Lawrence Chung u. a. Non-Functional Requirements in Software Engineering.

Google-Books-ID: MNrcBwAAQBAJ. Springer Science & Business Media, Dez.

2012. isbn: 978-1-4615-5269-7.

[23] Usage Statistics of HTTP/2 for Websites, October 2020. url: https : / /

w3techs.com/technologies/details/ce-http2 (besucht am 05. 10. 2020).

42

. QUELLENVERZEICHNIS

[24] RabbitMQ Summit talk recap: Scaling RabbitMQ at Goldman Sachs - Jonathan

Skrzypek - CloudAMQP. 10. Dez. 2018. url: https://www.cloudamqp.com/

blog/2018-12-10-keynote-scaling-rabbitmq-at-goldman-sachs.html

(besucht am 06. 10. 2020).

[25] egaillardon/jmeter-plugins - Docker Hub. url: https://hub.docker.com/r/

egaillardon/jmeter-plugins (besucht am 08. 10. 2020).

[26] RabbitMQ tutorial - Remote procedure call (RPC) — RabbitMQ. url: https:

//www.rabbitmq.com/tutorials/tutorial-six-python.html (besucht am

14. 10. 2020).

43

Anhang

A.1 Testdurchfuhrung

Die docker-compose Datei ist so konfiguriert, dass die drei Komponenten RabbitMQ,

die Spring Boot Serveranwendung und JMeter in eigenen Containern gestartet wer-

den. Der Container fur RabbitMQ bedarf keiner individuellen Konfiguration.

Die Container werden stets nacheinander gestartet und nicht alle auf einmal. Es

wird gewartet, bis der Container den Start vollstandig abgeschlossen hat, erst dann

wird der nachste Container initialisiert. Allgemein gilt die folgende Reihenfolge bei

der Initialisierung der Container:

1. docker-compose up -d rabbitmq

2. docker-compose up -d mvp

3. docker-compose up -d jmeter

Fur die Durchfuhrung der Tests mit HTTP/2 oder WebSockets werden nur die

Schritte 2 und 3 ausgefuhrt.

Bei den Containern der Spring Boot Anwendung und von JMeter bedarf es vor

Durchfuhrung eines Tests der individuellen Konfiguration. In der Serveranwendung

werden @Profiles genutzt, um storende Hintergrundoperationen zu vermeiden. Die

entsprechenden Profiles mussen vor Durchfuhrung eines Tests in Zeile 8 in [A.1]

ausgewahlt werden. Welche Profiles fur welchen Anwendungsfall benotigt werden

ist in Tabelle [A.1] beschrieben.

Fur den JMeter-Container muss der command spezifiziert werden. Hierbei wird in

Zeile 9 von [A.2] die mit JMeter erstellte Testdatei ausgewahlt und in Zeile 10 die

Resultat-Datei festgelegt. JMeter erstellt nach Ausfuhrung des Tests eine csv-Datei

mit den Ergebnismetriken.

44

A. Anhang

Anwendungsfall Technologie aktive Profiles

1 HTTP/2 -1 WebSocket -1 RabbitMQ messageQueues,receiver2 HTTP/2 -2 WebSocket -2 RabbitMQ messageQueues,receiver3 HTTP/2 -3 WebSocket -3 RabbitMQ messageQueues4 HTTP/2 -4 WebSocket -4 RabbitMQ messageQueues5 HTTP/2 -5 WebSocket wsDisconnect5 RabbitMQ messageQueues,mqDisconnect

Tabelle A.1: Aktive Profiles nach Anwendungsfall und Technologie

1 mvp :2 image : b t r e i t z /mvp : l a t e s t3 container name : mvp4 hostname : mvp5 por t s :6 − 8081:80817 environment :8 SPRING PROFILES ACTIVE :

#messageQueues , r e c e i v e r , mqDisconnect , wsDisconnect9 SPRING RABBITMQ HOST: rabbitmq

Quellcode A.1: docker-compose-Konfiguration fur die Spring Boot-Anwendung

1 jmeter :2 image : b t r e i t z / jmeter−p lug in s3 container name : jmeter4 hostname : jmeter5 t ty : t rue6 volumes :7 − . / s r c / [ . . . ] / Scenar i o s / : / jmeter8 command : −−nongui −Jjmetereng ine . f o r c e . system . e x i t=true9 −− t e s t f i l e / [ . . . ] / [ t e s t− f i l e −name ] . jmx10 −− l o g f i l e [ r e su l t− f i l e −name ] . csv

Quellcode A.2: docker-compose-Konfiguration fur Apache JMeter

45

A. Anhang

A.2 Messergebnisse

HTTP/2Szenario Durchl. 1 Durchl. 2 Durchl. 3 Arithm. Mittel Standardabw.

1 25 16 25 22 5,202 95 89 87 90,3 4,163 440 560 414 471,3 77,884 515 571 514 533,3 32,625 838 686 684 736 88,346 874 698 865 812,3 99,127 949 1067 759 925 155,408 1111 991 1206 1102,6 107,749 1192 1083 1125 1133,3 54,98

10 1599 1378 1559 1512 117,7611 1789 1544 1435 1589,3 181,3012 1571 1493 1497 1520,3 43,92

Tabelle A.2: Messergebnisse [in ms] fur Anwendungsfall 1 nach Objektanzahl - HTT-P/2

WebSocketSzenario Durchl. 1 Durchl. 2 Durchl. 3 Arithm. Mittel Standardabw.

1 21 38 39 32,6 10,122 84 49 65 66 17,523 230 155 151 178,6 44,504 187 176 264 209 47,955 294 282 238 271,3 29,486 366 287 329 327,3 39,537 392 514 345 417 87,238 - - - - -9 - - - - -

10 - - - - -11 - - - - -12 - - - - -

Tabelle A.3: Messergebnisse [in ms] fur Anwendungsfall 1 nach Objektanzahl - Web-Socket

46

A. Anhang

RabbitMQSzenario Durchl. 1 Durchl. 2 Durchl. 3 Arithm. Mittel Standardabw.

1 55 32 35 40,6 12,502 56 40 54 50 8,723 137 165 197 166,3 30,024 258 303 295 285,3 24,015 348 337 352 345,6 7,776 465 419 405 429,6 31,397 477 435 513 475 39,048 545 565 549 553 10,589 676 950 681 769 156,77

10 708 809 685 734 65,9611 713 773 785 757 38,5712 807 771 738 772 34,51

Tabelle A.4: Messergebnisse [in ms] fur Anwendungsfall 1 nach Objektanzahl - Rab-bitMQ


1 43 60 33 45,3 13,652 90 60 62 70,6 16,773 85 65 60 70 13,234 83 83 77 81 3,465 91 85 80 85,3 5,516 107 119 152 126 23,30

Tabelle A.5: Messergebnisse [in ms] fur Anwendungsfall 1 nach Objektgroße - HTT-P/2


1 37 89 64 63,3 26,012 101 109 65 91,6 23,443 125 117 126 122,6 4,934 113 112 139 121,3 15,315 168 108 126 134 30,796 173 187 128 162,6 30,83

Tabelle A.6: Messergebnisse [in ms] fur Anwendungsfall 1 nach Objektgroße - Web-Socket

47

A. Anhang


1 41 40 57 46 9,542 69 71 135 91,6 37,543 88 99 93 93,3 5,514 109 100 89 99,3 10,025 100 159 126 128,3 29,576 117 129 172 139,3 28,92

Tabelle A.7: Messergebnisse [in ms] fur Anwendungsfall 1 nach Objektgroße - Rab-bitMQ


1 572 425 420 472,3 86,352 429 425 624 492,6 113,763 460 421 552 477,6 67,26

Tabelle A.8: Messergebnisse [in ms] fur Anwendungsfall 2 - HTTP/2


1 521 425 415 453,6 58,532 575 508 553 545,3 34,153 690 592 650 644 49,27

Tabelle A.9: Messergebnisse [in ms] fur Anwendungsfall 2 - WebSocket


1 467 306 455 409,3 89,692 357 431 366 384,6 40,383 431 448 416 431,6 16,01

Tabelle A.10: Messergebnisse [in ms] fur Anwendungsfall 2 - RabbitMQ

HTTP Long PollingSzenario Durchl. 1 Durchl. 2 Durchl. 3 Arithm. Mittel Standardabw.

1 21,8 27,4 20,1 23,1 3,822 24,7 18,8 24,8 22,7 3,443 26,3 25,3 19,6 23,7 3,614 21,9 19 14,9 18,6 3,525 10,3 13,8 10,4 11,5 1,996 36,1 33 12,5 27,2 12,827 33,6 23,8 28,5 28,6 4,90

Tabelle A.11: Messergebnisse [in ms] fur Anwendungsfall 3 - HTTP Long Polling

48

A. Anhang


1 14,7 10,4 10,4 11,8 2,482 7,5 8,4 7,7 7,8 0,473 10,8 13 7,6 10,4 2,724 17,1 8 6,2 10,4 5,845 7,5 4,8 8,1 6,8 1,766 5,4 7,8 7,2 6,8 1,257 5,3 6,5 8 6,6 1,35



1 14,1 13,1 10,9 12,7 1,642 11,2 12,2 13,3 12,2 1,053 11,5 14,8 11,7 12,6 1,854 15,1 9,2 11,4 11,9 2,985 11,6 10,8 9 10,4 1,336 9,3 5,4 4,4 6,3 2,577 5,4 7,3 9,7 7,4 2,15


HTTP Long PollingSzenario Durchl. 1 Durchl. 2 Durchl. 3 Arithm. Mittel Standardabw.

1 32,5 33,9 32,7 30,0 5,502 67,7 69,3 49,5 62,2 10,973 80,2 47,6 69,7 65,8 16,634 89,8 71,2 78,5 79,8 9,345 84,4 87,4 99,1 90,3 7,806 134,4 95,7 106,4 112,1 19,967 200,6 253,9 177,7 210,7 39,088 169,2 135,9 150,4 151,8 16,729 180 148,2 216,5 181,5 34,15

10 160,3 170,6 135,7 155,5 17,9311 269,5 220,8 268,5 252,9 27,83

Tabelle A.14: Messergebnisse [in ms] fur Anwendungsfall 4 - HTTP Long Polling

49

A. Anhang


1 22,8 15,5 14 17,4 4,712 23,8 28,5 21,5 24,6 3,553 32,6 27,1 25,9 28,5 3,574 26,7 25,0 23,7 25,1 1,505 20,7 22,0 29,8 24,2 4,906 23,6 32,0 33,2 29,6 5,267 33,7 25,9 23,6 27,7 5,298 27,3 37,9 28,1 31,1 5,869 28,9 35 34,2 32,7 3,33

10 33 21,1 36 30,0 7,8811 25,9 38,4 58,6 40,9 16,50



1 61,6 12,1 11,5 28,4 28,742 26,6 33 25,2 28,2 4,143 33,4 33,5 42,5 36,4 5,274 48,1 61,2 38,1 49,1 11,585 56,4 46,2 47 49,8 5,666 59 64 72,6 65,2 6,887 70 76,9 79,5 75,4 4,918 103,9 65 70 79,6 21,169 92,1 99 101,6 97,5 4,88

10 112,2 98,6 92 100,9 10,3011 115,3 121,6 82 106,3 21,28



1 98,3 86,3 90,8 91,8 6,06



1 57,3 50,6 46 51,3 5,70


50

Comparison of data-communication technologies for a Real ...

Documents

Transcript of Comparison of data-communication technologies for a Real ...