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 von hoika:

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.