Performanteste Kommunikationsmethode zwischen Client u. Server

[inDex]

Guten Tag zusammen,

ich habe eine Frage bzgl. der Performance, wenn es darum geht regelmäßig und in kurzen Zeitabschnitten
zw. verschiedenen Rechnern in einem Netzwerk zu kommunizieren. Dafür kurz eine Beschreibung der Situation.

Ich habe einen Rechner ("Leitrechner") im Netz, welcher Daten über eine Schnittstelle bekommt und diese bearbeitet und verwertet,
sowie in eine Datenbank schreibt. Diese müssen im Nachgang im Sekundentakt an verschiedene weitere Clients im Netzwerk verteilt werden.
Zusätzlich müssen die Clients einige Befehle an den Leitrechner senden können, die er ausführen muss.

Bisher habe ich es wie folgt gelöst: Jeder Client baut sekündlich eine Connection zum Leitrechner auf (über ein TCP Socket, Leitrechner hat einen Connection-Pool und ist der Server), fordert die Daten an, bekommt diese geschickt und schließt die Verbindung wieder. Je nach Bedarf kann er weitere Befehle senden, wie oben beschrieben.

Ist das Performance-technisch die beste Variante?

• Sollten die TCP-Socket Verbindungen aller Clients lieber geöffnet bleiben?
• Wäre es performanter wenn die Clients die Daten sekündlich aus der Datenbank beziehen (sind dort eh schon vorhanden)?
• Wäre UDP und Broadcast eine Möglichkeit (Was ich eher nicht denke wegen Packet-Verlust, falsche Reihenfolge etc.)?
• Gibt es evtl. noch eine bessere Möglichkeit die ich nicht auf dem Schirm habe?

Vorab vielen Dank für mögliche Ideen/Anmerkungen/Vorschläge!

 

[LimDul]

Grundsätzlich gilt bei Performance-Analysen immer die Antwort "It Depends". Ohne Messungen ist es schwer was zu sagen.

Bauchgefühl: Verbindungsaufbau ist "relativ" teuer, daher würde ich dazu tendieren, die Verbindungen nicht abzubauen, wenn es in diesem Szenario bleibt.

Frage DB oder Kommunikation - da ist ein fundamentaler Unterschied - Push (Server sendet Daten an Client) vs. Poll (Client fragt DB ab). Da wäre die Frage, ob das nicht eher Auswirkungen hat und was davon sinnvoller ist. Auch ein DB Zugriff ist - solange es sich nicht um eine lokale DB handelt - auch immer mit TCP/IP Kommunikation verbunden + Overhead fürs Handling in der DB. Da würde ich eher bei der TCP/IP Verbindung bleiben

UDP: Nur wenn Reihenfolge relativ egal ist und einzelne Verluste auch kein Problem sind - ich glaube aber nicht an einen Performance Gewinn. UDP spielt seine Stärken meines erachtens aus, wenn Paketverluste egal sind und die Bandbreite höher ist. TCP hat ja ein Connection Handling, was die Paketgrößen dynamisch aushandelt. Solange es - wo ich jetzt erst mal von ausgehe - um eher geringe Datenmengen handelt, sehe ich da bei UDP keinen echten Mehrwert

Ich hätte aber noch eine andere Alternative - Message Queues. Die sind eigentlich genau dafür gedacht um Daten zwischen Systemen zu verteilen ohne das die Systeme alle direkt miteinander reden. Activemq wäre z.B. ein Vertreter davon. Die stellen sicher (bzw. man kann sie so einstellen), dass die Reihenfolge eingehalten wird, puffern Daten zwischen bis sie abgeholt werden (verkraften also auch, wenn ein System mal nicht erreichbar ist für ein paar Sekunden) etc.

 

[KonradN]

Sollten die TCP-Socket Verbindungen aller Clients lieber geöffnet bleiben?

Ein klares Ja. Damit ersparst Du Dir die ständige Kommunikation für Verbindungsauf- und -abbau.

Wäre es performanter wenn die Clients die Daten sekündlich aus der Datenbank beziehen (sind dort eh schon vorhanden)?

Das erspart den Zwischenschritt des Servers. Das kann also prinzipiell sinnvoll sein. Nur wenn die Verbindung zwischen Client <-> Server langsamer oder unsicherer ist, dann ist der zentrale Server eben performanter (und ggf. auch sicherer).

MessageQueue wurde von @LimDul angesprochen.

 

[inDex]

Die Methode mit Message Oriented Middleware und MessageQueue hört sich sehr interessant an. Die Messages können dabei auch synchronized Objects sein wenn ich das so auf die schnelle richtig erkannt habe (?). Würdet ihr gegenüber den TCP Sockets eher zu dieser Variante tendieren?

Dann werde ich vor erst einmal den Code so umschreiben, dass die TCP Connections offen bleiben und mich längerfristig in das Thema der MessageQueues einarbeiten und mein Code dann entsprechend abändern.

Vielen Dank für den Input soweit!

 

[mihe7]

Im Zusammenhang mit Message Queues wäre noch das "Protokoll des Internet of Things", aka MQTT, zu nennen. Da wird die Verbindung aufrecht erhalten, Verbindungsabbrüche "korrigiert", es gibt dort z. B. ein paar QoS-Einstellungen und der Spaß überträgt die Daten binär (das Protokoll ist für schwachbrüstige Clients wie kleine Sensoren ausgelegt).