TIdTCPServer und Parallel Library: Verwaltung von Threads

[romber]

Hallo!

Ich habe in meinem Programm einen TCP-Server, basiert auf Indy TIdTCPServer, der extrem zeitkritische Sensoren-Werte von mehreren Quellen übermittelt bekommt. Die empfangenen Daten müssen sehr schnell analysiert und verarbeitet werden, deswegen habe ich es damals so gemacht, dass für jedes Datenpaket einen neuen Thread für die Analyse gestartet wird. Gestern sind mehrere neue Datenquellen dazu gekommen mit dem Ergebnis, dass es mittlerweile bis zu mehrere Hundert Datenpakete pro Sekunde ankommen. Der Server läuft auf einem sehr modernen System aus 2 Xeon-Prozessoren, das jedes Jahr erneuert wird, großen Probleme gab es bis jetzt keine. Allerdings kam bei meinem Programm bereits einmal zu einer kurzen "Programm reagiert nicht" - Meldung, vermutlich, weil das System mit zu vielen gleichzeitig gestarteten Threads überlastet war. Bevor ich mir jetzt selber eine Queue für die ankommenden Daten baue und die Anzahl der Thread selber verwalte, möchte ich wissen, ob die vorhandene Delphi Parallel Library in diesem Fall eine Lösung wäre. Habe noch nie mit dieser Library gearbeitet, deswegen habe ich ein paar Fragen dazu.

- Da die Verarbeitungsreihenfolge nicht wichtig ist, wurde bis jetzt für jedes Datenpaket ein anonymer Thread gestartet, der nach Ablauf automatisch freigegeben wurde. Kann ich es genauso mit einem TTask machen oder muss ich hier was beachten?

(vielleicht meine wichtigste Frage an Indy-Experten)

- Wenn ich das richtig verstanden habe, werden TTasks von einem standardmäßig definierten ThreadPool verwaltet, der die maximale Anzahl der gleichzeitig möglichen Threads errechnet und die darüber hinaus laufende Tasks warten lässt, bis ein Platz frei ist. Sagen wir, der Server bekommt gleichzeitig sehr viele Datenpakete = Tasks, mehr als es laut dem ThreadPool geben darf. Einige Tasks müssen nun innerhalb des Execute-Events warten. Ist das im Fall Indy ein Problem? Können dadurch die Datenpakete verloren gehen? Muss ich hier was beachten?

- Jede Socket-Verbindung des TIdTCPServer "läuft" meines Wissens asynchron in einem separaten Thread. In meinem Fall können es bis zu 45 gleichzeitige Verbindungen sein. Werden diese Socket-Threads von Parallel Library berücksichtigt?

- Aus Ihrer Erfahrung, gibt es noch irgendwas, worauf ich besonders achten muss, wenn ich Parallel Library verwenden möchte?

Im Voraus vielen Dank!

[mjustin]

Werden die Cores des Servers gleichmäßig ausgelastet, oder kann man sehen dass das Serverprogramm nur einen Core verwendet (was ungünstiger wäre)?

[romber]

Zitat:

Zitat von mjustin (Beitrag 1356294)

Werden die Cores des Servers gleichmäßig ausgelastet, oder kann man sehen dass das Serverprogramm nur einen Core verwendet (was ungünstiger wäre)?

Ich weise den Threads zwar selber keine Kerne zu, aber laut Taskmanager werden alle Kerne bzw. logische Prozessoren (24) gleichmässig ausgelastet, sowohl in den ruhigeren Phasen als auch unter Vollast.

[mjustin]

Die von Indy erstellten Threads sind unabhängig vom Parallel Threadpool. Für jede Verbindung wird ein neuer Thread gestartet und die Execute Methode in einer Schleife immer wieder aufgerufen. Wenn Daten eintreffen, und in der der Execute-Methode an den Pool übergeben werden, blockiert die Execute Methode solange bis das Daten verarbeitet wurden. Daten im Socket gehen dadurch aber nicht verloren (den Socket kann man sich wie einen Stream vorstellen, aus dem man nach und nach so viel liest wie man möchte, und dazwischen auch Pausen machen darf).

Ist es ein Programm mit GUI? Die Meldung "Programm reagiert nicht" deutet ein wenig darauf hin... Dann würde ich vor allem versuchen, es komplett ohne GUI zu realisieren.

[romber]

Zitat:

Zitat von mjustin (Beitrag 1356308)

Ist es ein Programm mit GUI? Die Meldung "Programm reagiert nicht" deutet ein wenig darauf hin... Dann würde ich vor allem versuchen, es komplett ohne GUI zu realisieren.

Auf GUI kann ich leider nicht verzichten, weil ich die gewonnenen Daten ja irgendwie zu Ansicht bringen muss. An GUI soll das Problem aber nicht wirklich liegen. Die anonyme Threads greifen keinesfalls auf die GUI zu. Ein anderer zusätzlicher Thread, der für die Berechnung der Statistiken zuständig ist, greift zwar ab und zu auf die GUI zu, dabei werden die Zugriffe ausnahmslos synchronisiert. Die Überlastung durch diesen Thread schließe ich auch absolut aus.

Ich sollte die Frage zu den Socket-Threads vielleicht ein wenig umformulieren: Werden vom default ThreadPool beim Errechnen der noch "freien Plätze" auch die Thread berücksichtigt, die ausserhalb der Parallel Library erzeugt wurden? Oder bringt die Parallel Library in Hinsicht auf die Ressourcenverwaltung nur Sinn, wenn alle Threads innerhalb der Anwendung von Parallel Library abgeleitet werden?

[mjustin]

Wie die Parallel Library in diesem Punkt genau arbeitet, kann ich leider mangels Quelltext nicht sagen. Falls der Quelltext zu komplex ist um diese Frage zu beantworten, könnte eventuell eine Anfrage bei Stackoverflow schneller zu einem Ergebnis führen.

Das mit der Visualisierung ist verständlich, allerdings könnten 45 gleichzeitige Connections und hunderte Ereignisse pro Sekunde schon leicht dazu führen, dass die Anwendung durch das Zeichnen stark belastet wird. Eventuell kann man hier noch etwas sparsamer mit Ressourcen umgehen (Daten nicht erneut visualisieren, wenn die Werte nicht geändert haben etc.)

[romber]

Zitat:

Zitat von mjustin (Beitrag 1356320)

Das mit der Visualisierung ist verständlich, allerdings könnten 45 gleichzeitige Connections und hunderte Ereignisse pro Sekunde schon leicht dazu führen, dass die Anwendung durch das Zeichnen stark belastet wird. Eventuell kann man hier noch etwas sparsamer mit Ressourcen umgehen (Daten nicht erneut visualisieren, wenn die Werte nicht geändert haben etc.)

In diesem Punkt würde ich Ihnen natürlich Recht geben, wenn die Datenpakete-Threads auf die GUI irgendwie zugreifen würden. Dies tun die aber gar nicht. Die analysieren die Daten, filtern die relevanten Daten aus und fügen diese einem strukturierten, nicht visiellen, Datencontainer hinzu. Also, keine übermäßige Zugriffe auf GUI aus den Threads.

[mjustin]

Zitat:

Zitat von romber (Beitrag 1356322)

Zitat:

Zitat von mjustin (Beitrag 1356320)

Das mit der Visualisierung ist verständlich, allerdings könnten 45 gleichzeitige Connections und hunderte Ereignisse pro Sekunde schon leicht dazu führen, dass die Anwendung durch das Zeichnen stark belastet wird. Eventuell kann man hier noch etwas sparsamer mit Ressourcen umgehen (Daten nicht erneut visualisieren, wenn die Werte nicht geändert haben etc.)

In diesem Punkt würde ich Ihnen natürlich Recht geben, wenn die Datenpakete-Threads auf die GUI irgendwie zugreifen würden. Dies tun die aber gar nicht. Die analysieren die Daten, filtern die relevanten Daten aus und fügen diese einem strukturierten, nicht visiellen, Datencontainer hinzu. Also, keine übermäßige Zugriffe auf GUI aus den Threads.

So hatte ich das auch nicht geschrieben :) Ich meinte nur, dass das Programm sowohl die Daten empfängt, als auch visualisiert, könnte zu einer zu hohen Auslastung führen - was gelegentliche Hänger der Oberfläche erklären könnte. (Das sollte man im Taskmanager dann sehen können). Wenn die Auslastung nicht hoch ist und dennoch Hänger auftreten, wird es interessanter :)

[romber]

Die CPU-Auslastung springt kaum über die Marke vo 40% bei ca. 250 Datensätze pro Sekunde.

[taveuni]

Zitat:

Zitat von romber (Beitrag 1356316)

An GUI soll das Problem aber nicht wirklich liegen. Die anonyme Threads greifen keinesfalls auf die GUI zu. Ein anderer zusätzlicher Thread, der für die Berechnung der Statistiken zuständig ist, greift zwar ab und zu auf die GUI zu, dabei werden die Zugriffe ausnahmslos synchronisiert. Die Überlastung durch diesen Thread schließe ich auch absolut aus.

Doch! Ich habe jetzt nicht alles durchgelesen. Aber genau da liegt vermutlich das Problem. Wenn nämlich der Thread welcher synchronisiert warten muss passieren solche Sachen. Wir haben TCP Server im Einsatz (ICS) mit hunderten gleichzeitigen Socketverbindungen mit heavy Traffic. Da passiert gar nichts.