Anwendungs-GUI wird immer 'klebriger'. Wieso?

[alzaimar]

Tja, wie soll ich anfangen?

Diese Mist-Applikation ist ziemlich optimiert und ganz brauchbar implementiert; die GUI reagiert sofort (kein Wunder, ist ja alles in Threads organisiert). Was sie macht? Daten sammeln, in einer DB puffern und später zusammensuchen und weiter verschicken.

Zum Aufbau: 7 TCP-Threads empfangen ein paar Daten (XML, ca 10k pro Sekunde) und speichern die Daten mit den IB-Komponenten in einer Firebird-DB. Das Datenbankhandling übernimmt ein Workerthread, der die Daten streng sequentiell in die DB einpflegt, um Deadlocks zu vermeiden. Die Performance ist wirklich ok: Pro Sekunde werden 500 Datensätze plus einige Texte geschrieben.

Dann ist da noch ein (Indy) TCP-Server, der die Daten verschickt (auch in einem Thread).

Kontrollausgaben (Logging) erfolgt in 7 Memos über Window-Messages: Wenn es in irgend einem Thread etwas zu loggen gibt, wird der Text in einer Stringliste abgelegt und das Hauptformular per PostMessage angewiesen, diesen Text in einem der 7 Memos anzuzeigen. Das Befüllen der Memos erfolgt in einer separaten Message-Prozedur.

Daneben gibt es noch ein TChart, um einige Statistiken anzuzeigen, die durch einen Timer angezeigt werden. Das Problem besteht auch, wenn er Chart nicht neu gezeichnet wird.

Soweit zur Architektur.

Das Problem ist nun, das die Anwendung immer 'klebriger' wird, d.h. auf Mausklicks immer träger reagiert.
In einer Installation, auf die ich nur per VNC rankomme, wird die GUI fast gar nicht mehr neu gezeichnet: Nur die Hintergründe von Panels sowie die Memos und Umrandungen einer Listbox werden neu gemalt, wenn man mit einem anderen Fenster (Taskmanager, warum wohl ) über das Hauptformular fährt.

Wie kann das sein?
Wie kommt es dazu, das eine Anwendung immer klebriger wird, bis sie gar nicht mehr reagiert?
Läuft die MSQ über?
Dann würden aber die Log-Memos nicht geupdatet werden, oder?
Kann der Zugriff aud die Firebird-DB mit IB-Komponenten dazu führen (von einem Workerthread aus)?
Hat MSXML seine Finger im Spiel?
Vista?
Die Illuminaten?
Hansa?

Erschwerend kommt noch hinzu, das ich bei der Kundenanwendung per VNC nicht mitbekomme, das die Anwendung klebriger reagiert. Wenn ich nach einigen (2-16) Stunden nachschaue, ist entweder alles in Butter oder es geht gar nix mehr.

Das mit dem 'langsam klebriger werden' sehe ich nur in einer Simulation, die aber nicht komplett das reale Szenario wiederspiegelt.

Nochmal die Fakten:
7 x TCP-Thread (non blocking, im Thread mit eigener MSQ), ca. 10k pro Sekunde, MSXML, Daten per separatem Workerthread und IB-komponenten in eine Firebird-DB.
1 x Indy-TCP-Server in separatem Thread, verschickt Daten (über den DB-Workerthread auslesend).
Log-Ausgaben per individuellen Threads und Postmessage an die Hauptanwendung.
1 x Steema-Chart für Statistik, die per Windows-Timer 1x pro Sekunde angepasst wird.

Könnt ihr mir ein paar Denkanstöße geben, was ich noch einbauen oder wo ich suchen kann?
Steh hier völlig im Regen, hab das Logging schon ausgetauscht, den TCP-Client neu gebaut. Wattennunochallet?
Ich hab schon einen Sentinel, der per SendMessageTimeout prüft, ob die MSQ des Hauptformulars hängt (Timeout 5 Sekunden), aber seit dem ich den installiert habe, funktioniert natürlich alles (Dauert eben bis zu 16 Stunden, bis es mal wieder hängt).

[sirius]

Die Indy-Komponenten (ich kenne nur Version 9) sind eher so aufgebaut, dass man diese nicht in Threads legen sollte. Sie arbeiten intern mit TThread, welcher wiederum mit Synchronize arbeitet um gewisse Ereignisse in den aufrufenden Thread (wo Indy initialisiert wurde) zu leiten. Synchronize ist aber dafür ausgelegt sich NUR mit dem MainThread zu synchronisieren, da es über das globale Application-Objekt arbeitet. Jetzt könnte ich mir an dieser Stelle vorstellen, dass das Application-Objekt so nach und nach überläuft und deswegen nicht mehr in den idle Zustand kommt.

War jetzt nur so meine erste Idee.

Edit: Warum legt man Socket-Komponenten in einen Thread, wenn man sie dann auf Non-Blocking setzt?

[Astat]

Hallo alzaimar;

Zitat von alzaimar:

Tja, wie soll ich anfangen?

Speicherauslastung:
Wird das Programm erst zäh wenn der Speicherverbrauch steigt?
Kann ein Hinweis sein, das TStrings von TStringListen und oder Memos voll laufen.

GDI-Objecte (Handles) laufen über:
Kontrols werden nicht mehr korrekt gezeichnet.

Suchen in allen Dateien nach Sleep:
Es Sollten keine Treffer angezeigt werden.
Zum Synchronisieren und Warten sind Sleeps ungeeignet.

Suchen in allen Dateien nach Processmessages:
Auch hier gilt, vollkommen ungeeignet um auf etwas zu warten oder zu sysnchronisieren.

Sampling Profiler Verwenden.

Für Hochlast TCP-IP Anwendungen keine Komponenten verwenden, nativeen Transport codieren.


lg. Astat

[thkerkmann]

Hi,

ich sehe das wie Sirius: Keine non-blocking Socket Komponenten in Threads (Ok, ich bin ein Fan von synapse).

Und ich würde mir sehr genau das String Management ansehen. Eventuell muss das optimiert werden.
Memos sind zum Loggen auch nicht wirklich geeignet. Habe da bessere Erfahrungen mit Listboxen gemacht. Max. 4k Zeilen und dann die unteren wieder wegnehmen. Und schön Lines.BeginUpdate/EndUpdate verwenden.

Gruss

[himitsu]

Du hast ja "massenhaft" Threads ... greifen diese eventuell zu oft auf die GUI zu?
(sowas sollte ja synchronisiert sein, was bei übermäßigem Zugriff arg ausbremst)

Zitat:

Hat MSXML seine Finger im Spiel?

Wieviel verwendest du davon?
(ist ja nicht der schnellste)

[alzaimar]

Zitat von sirius:

Die Indy-Komponenten ... mit Synchronize arbeitet...

Dachte ich mir... Werde ich wohl ändern.

Zitat von sirius:

Warum legt man Socket-Komponenten in einen Thread, wenn man sie dann auf Non-Blocking setzt?

Spielerei. Könnte ich auch auf "blocking" setzen, aber erstmal muss man verstehen, um es zu ändern. Ich habs nun kapiert, dank ...

Zitat von Astat:

Speicherauslastung?

Nein. Das ist sauber. Hab schon FastMM drübber laufen lassen.

Zitat von Astat:

GDI-Objecte (Handles) laufen über:

Sollte ich das Uralt MemProof mal drüber laufen lassen?

Zitat von Astat:

Suchen in allen Dateien nach Sleep,... Processmessages...

Zitat von Astat:

Sampling Profiler Verwenden.

Zum Bleistift? Irgendwas, was umme is?

Zitat von Astat:

Für Hochlast TCP-IP Anwendungen keine Komponenten verwenden, nativen Transport codieren.

Bin ich sonst kein Freund von (lieber Baukastenprinzip). Aber das das in die Hose gehen kann, sieht man an den Indies

Zitat von thkerkmann:

ich sehe das wie Sirius: Keine non-blocking Socket Komponenten in Threads

Ist doch nur overkill, aber keine Bremse, oder?

Zitat von thkerkmann:

Memos sind zum Loggen auch nicht wirklich geeignet. Habe da bessere Erfahrungen mit Listboxen gemacht. Max. 4k Zeilen und dann die unteren wieder wegnehmen. Und schön Lines.BeginUpdate/EndUpdate verwenden.

Nee, nee, ich schnippel die schon auf max 100 Zeilen.

Zitat von himitsu:

Du hast ja "massenhaft" Threads ... greifen diese eventuell zu oft auf die GUI zu?

Derzeit ca. 30-40. Teilweise Quatsch, aber von mir aus kann das lahm sein. Aber es soll eben micht zulaufen.

Zitat:

Hat MSXML seine Finger im Spiel?

Pro TCP-Client 1x pro Sekunde ein Telegramm. Hab ja schon an Himicks-ml gedacht...

Also: Ich schmeiss die Indies komplett raus und suche nach 'Sleep' und 'ProcessMessages' und dampfe die Threads mal ein.

Ich hab den Server (Indy) auch im Verdacht, weil die Anwendung schon zuckelt, wenn ich mal 1.6MB XML verschicke, und das in einem Thread. Sollte man ja eigentlich gar nicht merken...

Wie gesagt: Es ist keine Hochlastanwendung und muss nicht optimiert werden. Es reicht mir, wenn die Anwendung stabil läuft. Erstmal.

[Astat]

Hallo alzaimar.

Zitat von alzaimar:

Also: Ich schmeiss die Indies komplett raus und suche nach 'Sleep' und 'ProcessMessages' und dampfe die Threads mal ein.

Ich hab den Server (Indy) auch im Verdacht, weil die Anwendung schon zuckelt, wenn ich mal 1.6MB XML verschicke, und das in einem Thread. Sollte man ja eigentlich gar nicht merken...

Wie gesagt: Es ist keine Hochlastanwendung und muss nicht optimiert werden. Es reicht mir, wenn die Anwendung stabil läuft. Erstmal.

Als Faustformel gilt: Maximal 8 Threads per CPU um die Kosten (Threadscheduling, Stack-Sicherung usw.) gering zu halten.

Wenn Du Verwendung dafür hast, kannst du beigelegte Native Socket Libraries verwenden.
Diese sind getestet (WAN mit 50000 Client PC's) und über mehrere Jahre hinweg stetig weiterentwickelt worden.
Samples incl Source wie die DLL's zu verwenden sind, ist beigefügt.
Die Verwendung ist denkbar einfach.

Mit Connect eine Verbinden aufbauen.
In der Methode send kannst Du beliebige daten senden, der Rest (Header, Kompression, Empfangsbuffer Aufbereitung usw.)
erledigt die Dll unsichtbar im Hintergrund, also wie eine Komponente als Black Box.

Lg. Astat

[WoGe]

Zitat von alzaimar:

Wie gesagt: Es ist keine Hochlastanwendung und muss nicht optimiert werden. Es reicht mir, wenn die Anwendung stabil läuft. Erstmal.

Schau mal, ob alle Indices vorhanden bzw. angeschaltet sind. Ich habe das mal bei einem Programm gehabt, das ein abgeschalteter Index für hohe CPU-Last gesorgt hat und das in dem Proggie, das die Daten geliefert hat nicht mehr viel ging.

Gruss wo

[Astat]

Zitat von alzaimar:

Zitat von Astat:

Speicherauslastung?

Nein. Das ist sauber. Hab schon FastMM drübber laufen lassen.

Hallo alzaimar, hab hier an den Taskmanager (DasBesagteProgramm.exe) und an Speichernutzung und Virtueller Speicher gedacht.
Dass ein Memoryleake vorhanden ist, hab ich sowiso bei dir nicht angenommen!!

lg. Astat