Zitat von 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)?

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.

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.

Zitat von mjustin:

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?

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.)

Zitat von mjustin:

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.

Zitat von romber:

Zitat von mjustin:

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

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

Zitat von romber:

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.

Zitat von taveuni:

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.

Denkbar wäre es. In meinem Fall aber platziert der Thread mit .Queue() eine Anweisung an den Hauptthread, deren Ausführung nicht mehr von Thread abhängt, und befördert sich ins Jenseits. Muss gar nicht warten.