Multithreading-Projekt: PPL oder OmniThreadLibrary?

[romber]

Ich stehe vor einer Aufgabe, die ich ohne den gut durchdachten Multi-Threading werde wahrscheinlich nicht lösen können.

Folgender Aufgabe: Über zwei WebSocket-Verbindungen bekomme ich extrem viele Datenpakete (bis zu 500 pro Sekunde, bis zu 4 KB groß). Bei den Datenpaketen handelt es sich um die Sensorendaten, die möglichst schnell verarbeitet und visualisiert werden müssen. Mit „möglichst schnell“ ist gemeint, dass jede vermeidbare Verzögerung vermieden und dadurch die max. mögliche Performance erreicht werden soll. Andererseits soll das Ganze stabil bleiben und das System nicht extrem überlasten.

Jedes empfangene Datenpaket muss folgende Schritte durchlaufen:

1. Entschlüsseln

2. Die entschlüsselten XML- oder JSON-Daten in einen Objekt (oder Record) umwandeln.

3. Eine n Zahl der vordefinierten Filter durchlaufen, wodurch das Objekt durch zusätzliche Daten ergänzt wird. Hier finden nun auch Zugriffe (u.a. schreibende) auf die Variablen der Filter-Objekte statt, die potenziell aus mehreren parallel laufenden Threads erfolgen können. Diese Zugriffe müssen mit möglichst geringen Performanceeinbüßen geschützt werden.

4. Hinzufügen des neuen Objekts einem thread-sicheren Container, der als Custom Data Source für die DevExpress Quantum Grid dient. Was das am besten für ein Container sein soll, ist auch eine Frage.

5. Visualisieren des Objektes in einem Grid.

6. Darstellung der Objektdaten in einem Chart.

7. Eventuell Ausgabe eines akustischen Signals.

Die Datenpakete seriell zu verarbeiten kommt bei der Menge der Daten nicht infrage. Jedes Datenpaket unkontrolliert einem neuen Thread zuzuweisen und hoffen, dass alles glatt läuft, auch. Es muss also ein cleverer Thread-Manager her, der für den schnellen und stabilen Ablauf bei möglichst vielen parallel laufenden Tasks sorgt. Ich habe an Parallel Programming Library oder OmniThreadLibrary gedacht.

Ich lese gerade viel über OmniThreadLibrary und je mehr ich lese, desto stärker neige ich dazu, das Ganze mit der Library zu realisieren. Es scheint einfach so, dass die Bibliothek für jede erdenkliche Situation eine passende fertige Lösung hat und dabei auf Performance ausgelegt ist.

Wie würdet Ihr das Ganze realisieren? Für möglichst detaillierte Gedankenäußerungen und kleine Code-Bespiele für das bessere Verständnis bedanke ich mich im Voraus!

[haentschman]

Moin...8-)

Gedanken dazu:

Zitat:

bis zu 500 pro Sekunde, bis zu 4 KB groß

Für die Visualisierung reichen imho ca. 10 Datensätze pro Sekunde. Kein Visuelles Control kommmt (bis zu 500 pro Sekunde, bis zu 4 KB groß) damit mit. Erst Recht nicht DevExpress. Dein Problem wird aber sein (ohne die Visualisierung), die gelesen Datensätze zu verarbeiten und den Speicher wieder freizumachen. Datenbank ist langsamer. (Spermanente Speicherung?) Der Flaschenhals wird die visuelle Ausgabe sein. (Grid, Chart).

PS: Welches Meßgerät liefert die Meßdaten in 2ms Rhytmus? Welcher Meßzeitraum wird betrachtet? 10s oder 24h?

[Schokohase]

Zitat:

Zitat von romber (Beitrag 1435861)

3. Eine n Zahl der vordefinierten Filter durchlaufen, wodurch das Objekt durch zusätzliche Daten ergänzt wird. Hier finden nun auch Zugriffe (u.a. schreibende) auf die Variablen der Filter-Objekte statt, die potenziell aus mehreren parallel laufenden Threads erfolgen können. Diese Zugriffe müssen mit möglichst geringen Performanceeinbüßen geschützt werden.

Bei Multi-Threading ist aber die Reihenfolge in der die Daten verarbeitet werden nicht mehr absehbar, somit würden die gleichen Daten bei jedem Durchgang andere Ergebnisse produzieren.

Ist das so gewollt bzw. hast du daran gedacht?

[romber]

Zitat:

Zitat von haentschman (Beitrag 1435863)

Für die Visualisierung reichen imho ca. 10 Datensätze pro Sekunde. Kein Visuelles Control kommmt (bis zu 500 pro Sekunde, bis zu 4 KB groß) damit mit.

Im Schnitt sind es etwa 75 pro Sekunde. Tatsächlich spielen nur etwa 10-20% der Datensätze bei die Visualisierung direkt eine Rolle, der Rest sind Metadaten, die jedoch auchg nicht unterschätzt werden dürfen. Genau diese Metadaten laufen durch die im Schnitt 2 erwähnten Filter und sorgen unter Umständen für die Korrekturen bei der vusuellen Darstellung.[/QUOTE]

Zitat:

Zitat von haentschman (Beitrag 1435863)

PS: Welches Meßgerät liefert die Meßdaten in 2ms Rhytmus? Welcher Meßzeitraum wird betrachtet? 10s oder 24h?

Die Sensoren sind ein Teil eines spektrometer-ähnlichen Gerätes in der Chemie. Die zu überwachende Reaktionen können länger als 24h andauern.

Zitat:

Zitat von Schokohase (Beitrag 1435871)

Bei Multi-Threading ist aber die Reihenfolge in der die Daten verarbeitet werden nicht mehr absehbar, somit würden die gleichen Daten bei jedem Durchgang andere Ergebnisse produzieren.

Bei der Art der Änderungen, die an den Filter-Variablen vorgenommen werden, spielt die Rehenfolge der Verarbeitung keine Rolle.

[Mavarik]

Ich arbeite an einem ähnlichen Projekt...

Ich nehme weder die PPL noch etwas anderes "von der Stange". Alle Threads erzeuge ich selber mit eigener Logik für die Verwaltung.

Ein gutes Queue-Konzept ist hier der Schlüssel zum Erfolg.

Mavarik

[romber]

Zitat:

Zitat von Mavarik (Beitrag 1435890)

Ein gutes Queue-Konzept ist hier der Schlüssel zum Erfolg.

Würden Sie Ihr Queue-Konzept etwas genauer erläutern?

[Mavarik]

Zitat:

Zitat von romber (Beitrag 1435897)

Würden Sie Ihr Queue-Konzept etwas genauer erläutern?

Klar... Was genau möchtest Du wissen?

Mavarik