Grundsatzfrage: Datenbanken und Parallelausführung

[Codehunter]

Moin!

Ist es möglich bzw. sinnvoll, Datenbankoperationen (auch UPDATE, INSERT, DELETE) aus einem Thread/Task/whatever heraus zu tätigen? Ich bin an einem Themenblock dran, der sich eigentlich sehr gut für Parallelisierung eignen würde. Der ganze Aufgabenblock ist schon ordentlich gekapselt und erzeugt bereits seine eigenen Queries und Transactions. Ich müsste nur noch jedem Thread eine eigene Connection geben. Dann wären sie tatsächlich unabhängig vom Mainthread. Eine Synchronisierung ist nur sehr selten bis fast gar nicht notwendig, weil es zwischen Thread und Mainthread keine Interaktion/Visualisierung geben braucht. Allerdings weiß ich eben nicht, wie Threadsafe die FIB Pro Tools sind.

Zweite Möglichkeit die ich mir vorstellen könnte wäre es, die Aufgabe nur teilweise zu parallelisieren. Es sind auch Online-Abfragen mit Indy im Spiel, welche für die Latenzen sorgen, die mich überhaupt erst auf die Idee gebracht haben. Die Datenbankoperationen würde ich dann im Hauptthread synchronisiert ausführen. Wäre machbar, weil die DB-Operationen schnell erledigt sind (lohnt sich nicht mal eine Eieruhr).

Bevor ich da aber viel Arbeit vergeblich rein stecke wollte ich einfach mal eure Meinung dazu.

Grüße
Cody

[hoika]

Hallo,

DB: wenn es nicht sein muss, lass es bleiben. Wenn Du schon schreibst, dass es sehr schnell geht, dann mach es im Hauptthread.
Indy: wenn du der Meinung bist, dass es parallel laufen soll, gut

Multithreading kann einen Haufen Probleme erzeugen, gerade wegen der Nebenläufigkeit.
Das zu debuggen, kann sehr aufwändig sein.

[HolgerX]

Hmm..

(Kenne FB nicht wirklich)

Da Änderungen (Inser/Update/Delete) auf der selben Tabelle im Regelfall auch eine Änderung an nem Index ausführt, werden solche Sachen ja eigentlich in einer Transaktion, somit seriell (nacheinander) seitens der DB ausgeführt.

Dadurch dürfte es keine merkbare Geschwindigkeitssteigerung geben.

(Nur so aus dem Bauch heraus ;) )

Thread und DB nur dann, wenn seitens des Treads eine u.U. längere Verarbeitung gemacht und anschließend nur einen kurzen DB-Zugriff.

[jobo]

Wenn Du bereits von hoher Performance beim Insert/Update/Delete ausgehst, also keine lang anhaltende Operation, dann brauchst Du keinen Thread. Insbesondere wenn es echte Query Operationen sind, die nicht mit Dataset, geschweige mit GUI verbunden sind.
Threading würde ich tatsächlich auch eher für die von Dir genannte, lahme "Online" Operation nehmen.

DB Threads bieten sich m.E. an, wenn es entweder um längere Operationen geht oder um eine schlechte, schmale oder wackelige Anbindung (LTE, ...)

Grundsätzlich ist ein Threading in der Datenanbindung natürlich auch eine schicke Sache, denn sie bringt sicher flüssigere Bedienung der Anwendung. Aber man bekommt es nicht geschenkt und handelt sich u.U. ein paar Probleme ein, wie schon geschrieben wurde.

[Schokohase]

• Wie threadsafe sind ...?
  
  In dem skizzierten Szenario spielt das so keine Rolle, da die Instanzen ja nicht zwischen den Threads geteilt werden. threadsafe ist nur dann interessant, wenn mehrere Threads gleichzeitig darauf zugreifen können sollen.
  
  
• Nur die Datenbank-Operationen im Thread
  
  Ist eigentlich Perlen vor die Säue, denn was macht dieser Thread? Er schläft bis die Aufgabe erfüllt ist. Besser wäre hier eine asynchrone (nebenläufige) Ausführung (siehe Asynchrone Ausführung (FireDAC))

[Codehunter]

In dem Zusammenhang ist mir jetzt aufgefallen, dass das Erzeugen einer TIdHTTP-Instanz eine Menge Zeit fressen kann. Das ergibt bei folgendem kleinen Test interessante Messwerte:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  tasks: array of ITask;
  I: Integer;
  Startzeit: Integer;
begin
  Startzeit := GetTickCount;
  SetLength(tasks, 40);

  for I := Low (tasks) to High (tasks) do
      begin
    tasks[I] := TTask.Create (procedure ()
    var
      HTTP: TIdHTTP;
      S: string;
    begin
      HTTP := TIdHTTP.Create(NIL);
      try
        HTTP.Get('http://irgendeinserver.de/');
      finally
        HTTP.Free;
      end;
    end);
    tasks[I].Start;
  end;

  TTask.WaitForAll(tasks);
  Memo1.Lines.Add('Das Ausführen dauerte '+IntToStr(GetTickCount - Startzeit)+' Ticks');

end;

procedure TForm1.Button2Click(Sender: TObject);
var
  HTTP: TIdHTTP;
  Startzeit: Integer;
  S: string;
  I: Integer;
begin
  Startzeit := GetTickCount;
  HTTP := TIdHTTP.Create;
  try
    for I := 1 to 40 do begin
      S := HTTP.Get('http://irgendeinserver.de/');
    end;
  finally
    FreeAndNil(HTTP);
  end;
  Memo1.Lines.Add('Das Ausführen dauerte '+IntToStr(GetTickCount - Startzeit)+' Ticks');
end;

procedure TForm1.Button3Click(Sender: TObject);
var
  HTTP: TIdHTTP;
  Startzeit: Integer;
  S: string;
  I: Integer;
begin
  Startzeit := GetTickCount;
  for I := 1 to 40 do begin
    HTTP := TIdHTTP.Create;
    try
      S := HTTP.Get('http://irgendeinserver.de/');
    finally
      FreeAndNil(HTTP);
    end;
  end;
  Memo1.Lines.Add('Das Ausführen dauerte '+IntToStr(GetTickCount - Startzeit)+' Ticks');
end;

Button 1: 300 bis ~3000 Ticks (im Mittel 1100 Ticks)
Button 2: ~1500 Ticks
Button 3: ~3000 Ticks

Besonders aus den letzteren beiden Varianten ohne Multithreading lässt sich ableiten, dass das Erzeugen vom TIdHTTP-Objekt bei einem seriellen Ablauf und halbwegs flottem Server die Laufzeit in etwa verdoppelt bzw. das Erzeugen genauso lang dauert wie der HTTP-Request selbst. Die genannten Zahlen habe ich aus jeweils 10 Durchläufen a 40 Abrufen ermittelt.

Da ich aber in der Multithreading-Variante das Objekt nicht mehrfach verwenden kann, muss ich zwangsläufig für jeden Task ein eigenes TIdHTTP erzeugen. Dadurch relativiert sich Aufwand und Nutzen zwischen der Variante 1 (mit Threading) und Variante 2 (seriell mit einmal erzeugter TIdHTTP-Instanz) doch ganz erheblich. Wobei ich noch nicht dahinter gekommen bin woher die enorme Streubreite bei Variante 1 kommt. An Serverlatenzen liegt es nicht, das sieht man an den seriellen Varianten, da reagiert der sehr konstant.

PS: "http://irgendeinserver.de/" müsst ihr ersetzen durch einen Testerver eurer Wahl.

[Schokohase]

Wenn du messen willst, wie lange das Erzeugen einer Instanz dauert, dann erzeuge nur und ausschließlich die Instanz. Machst du irgendetwas anderes noch dabei, dann misst du einfach nur gequirlten ....

Gerade bei einer Netzwerkverbindung fallen mir tausend Dinge ein, die dort die Zeit beeinflussen können.

[Codehunter]

Das ist mir alles klar. Die Frage dreht sich aber darum, wie man die Latenzen in solchen Szenarien drücken kann. Und da ist es sehr wohl interessant zu sehen, wie es sich in der Praxis verhält. Denn was nützt mir die schönste/aufwendigste Parallelisierung, wenn ich im Ergebnis vielleicht 10% Zeit gewinne? Um den Bogen zur Ausgangsfrage zu schließen: Ich müsste ja je Thread nicht nur das HTTP-Objekt erzeugen sondern auch Queries, Transactions usw.

Der einzige Vorteil den ich im Moment sehe ist, dass ich Tasks generell laufzeitbegrenzen kann. Aber dann fehlt mir bei einer Zeitüberschreitung ein Teil vom Ergebnis.

[hoika]

Hallo,

Zitat:

sondern auch Queries, Transactions usw.

Genau so ist es. Man könnte sogar die Connection selbst neu erzeugen.
Das verlangsamt das aber alles noch mehr wegen den mehrfachen Connects.

Die DB-Komponenten müssen bei einer gemeinsamen Connection
dann aber threadsafe sein, weil ja die Connection nur einmal vorhanden ist.

[Codehunter]

Zitat:

Zitat von hoika (Beitrag 1413381)

Genau so ist es. Man könnte sogar die Connection selbst neu erzeugen.
Das verlangsamt das aber alles noch mehr wegen den mehrfachen Connects.

Die DB-Komponenten müssen bei einer gemeinsamen Connection
dann aber threadsafe sein, weil ja die Connection nur einmal vorhanden ist.

Siehe Eingangsfrage. Man kommt ums Praxistesten gar nicht herum. Denn selbst wenn man die Datenbank komplett aus dem Multithreading raus lässt gibts immer noch mehrere Wege wie man verfahren kann. Zum Bsp. Ergebnisdatenmengen erstmal in Record-Arrays zwischenspeichern und dann in einem Rutsch im Mainthread in die Datenbank wuppen. Da hat man dann aber eine Menge Allokation. Oder man synchronisiert jede Datenbankschreiberei. Wobei zumindest auf meinem Testsystem jegliches Synchronize sehr negativ auf die Laufzeiten wirkt.

[MyRealName]

Ich arbeite mit Threads und Datenbanken, Du musst nur
a) sicherstellen, dass alles wirklich in dem Kontext auch wirklich nur im Kontext benutzt wird
b) jeder Thread seine eigene Db-Verbindung hat. Ich selbst nutze Firebird mit UniDAC btw.

[Mavarik]

Welches Threading Du wie benutzen solltest, hängt auch von der Datenbank ab.

Also File-basierte Datenbank mögen es nicht, wenn mehrere Connections aus mehreren Thread gleichzeitig zugreifen.

Abgesehen davon : ALLES absolut ALLES was nicht mit der Oberfläche arbeitet gehört für mich in einen Thread, besonders in FMX da hier die UI-Thread
möglichst nix anderes machen sollte.

Für die Datenbank solltest Du also einen Serialisierer bauen, der alles Datenbank Operationen nacheinander abarbeiten kann.

Je nachdem wie Dein Zielsystem aussieht, kannst Du für alles andere entweder die TPL nehmen oder baust Dir eigene Threads. Hier kann ein Thread auch gerne mehrere Aufgaben übernehmen. Ich würde mir in so einem Fall einen WorkData-Wrapper bauchen, der für jede Aufgabe die Daten bereithalten kann und diese dann per Queue an den WorkerThread übergibt.

Die Entscheidung ob TPL oder pre-Started Thread ist für mich immer die Frage der Reaktionszeit. Ein Thread der per TPL erzeugt wird hat immer etwas overhead bis die eigentliche Verarbeitung startet. Ein Thread der nur auf einen Setevent warten startet sofort. Die Zeit bis der Worker startet is nahezu nicht messbar. (Unter 16ps wenn ich es richtig im Kopf habe. "System abhängig").

Wenn Du für jede Aufgabe einen eigenen Thread erzeugst und diese per

Delphi-Quellcode:

FEvent.Wait(INFINITE);

darauf warten etwas leisten zu müssen, verbrauchen diese Thread keine CPU-Zyklen.

Grüsse Mavarik

[MyRealName]

Wenn Du Geld ausgeben kannst um Zeit zu sparen : RealThinClient hat eine Komponente, die TRtcQuickJob heisst. Die nutzt einen Threadpool und du kannst die Sachen auch serialized einwerfen, dann werden die nacheinander abgearbeitet. Hast Du mehrere Datenbanken gleichzeitig, machst einfach mehrere TRtcQuickJobs. das hatte ich damalas genommen und das hat in 3 Zeilen all meine Probleme gelöst