Grundsatzfrage: Datenbanken und Parallelausführung

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

[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 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