Querystring präparieren

[jobo]

Ja, ausprobieren ist gut!

Ich denke, je größer der Loopcount, desto eher macht sich das bemerkbar.
Hunderte oder tausende von Aufrufen dauern dann halt mit Parameterbestückung etwas länger.

Mglw. ist das aber nur in der Theorie bemerkbar, weil idR die Größe eines Blocks auch beschränkt ist. Weiß nicht, wie das firebird handhabt.

Am Ende macht es wahrscheinlich keinen großen Unterschied. Dann kommt man an den Punkt, die SP selbst zu optimieren.

[Schokohase]

Ich weiß nicht ob es jemandem aufgefallen ist:

Mein Ansatz zielt darauf ab die Aufrufe in einem Rutsch an den Server zu schicken, aber trotzdem mit Parametern.

Es wird also in einem Aufruf dieses Statement abgearbeitet:

SQL-Code:

EXECUTE PROCEDURE MY_PROC(:p1_0,:p2_0,:p3_0);
EXECUTE PROCEDURE MY_PROC(:p1_1,:p2_1,:p3_1);
EXECUTE PROCEDURE MY_PROC(:p1_2,:p2_2,:p3_2);
EXECUTE PROCEDURE MY_PROC(:p1_3,:p2_3,:p3_3);
EXECUTE PROCEDURE MY_PROC(:p1_4,:p2_4,:p3_4);
...
EXECUTE PROCEDURE MY_PROC(:p1_n,:p2_n,:p3_n);

und nicht n mal
EXECUTE PROCEDURE MY_PROC(:p1,:p2,:p3);

[Codehunter]

Könnte es evtl. sein dass ihr übersehen habt, dass es hier nicht um FireDAC sondern um FIBplus geht? Da unterstützt TFIBQuery keine Multiline-Queries und TpFIBScripter keine benannten Parameter. Insofern endet das Ausprobieren in einem "Invalid token...".

Firebird 2.5 unterstützt nur recht kleine Blöcke, sodass ich bei dynamisch berechneter Blockgröße in diesem Fall zwischen 50 und 90 Queries in einem Rutsch absetzen kann. Ich habs jetzt testweise mal ohne "Injection-Schutz" mit einem schnöden Format() implementiert. Ggü. der vorigen Implementierung mit dem zeilenweisen Aufrufen der Storedproc ist die Laufzeit von knapp 21 Minuten auf 21 Sekunden gesunken (bitte keine Witze dazu, ich habe weder die Storedproc noch das DB-Design zu verantworten). Das korrelliert insofern mit der Anzahl Zeilen je EXECUTE BLOCK.

Am Rande bemerkt empfinde ich die Einschränkungen von Firebird ggü. z.B. MariaDB wie eine Eisenkugel am Bein. MariaDB/MySQL kann Multi-Row-INSERT, was mir hier den Aufruf der Storedproc erspart hätte. Gut, FB 2.5 ist schon älter, aber in 3.0 wurde es ja auch kaum besser. Gibts da chon Erfahrungen mit der 4.0?

[jobo]

Zitat von Codehunter:

.. ist die Laufzeit von knapp 21 Minuten auf 21 Sekunden gesunken (bitte keine Witze dazu, ich habe weder die Storedproc noch das DB-Design zu verantworten).

Ich mache nie Witze!

Die Laufzeitänderung überrascht mich nun doch sehr, mit so einem starken Unterschied hätte ich nicht gerechnet. Nicht jedenfalls bei unter 100 Aufrufen.

Irgendwie scheint da noch was anderes im Spiel zu sein.

[Codehunter]

Zitat von jobo:

Die Laufzeitänderung überrascht mich nun doch sehr, mit so einem starken Unterschied hätte ich nicht gerechnet. Nicht jedenfalls bei unter 100 Aufrufen.

Irgendwie scheint da noch was anderes im Spiel zu sein.

Auf jeden Fall. Zum Beispiel wurde konstruktionsbedingt nicht nur je Aufruf der Storedproc ein TFIBStoredProc-Objekt erzeugt und freigegeben sondern auch noch jeweils eine Transaktion gestartet und Committed. Zudem läuft der Client in einer VM, worunter die Netzwerkperformance zum DB-Server insbesondere bei vielen kleinen Paketen erfahrungsgemäß leidet. Typischer Fall von gewachsenen Strukturen. Aber aus einem Eselkarren macht man im Handstreich eben keinen Sportwagen sondern bestenfalls eine Postkutsche

[EgonHugeist]

Hallo Cody,

schau da mal rein: https://zeoslib.sourceforge.io/viewt...?f=50&t=129484 ich habe for Zeos8 BatchArray bindings auf dem Component-Layer hinzugefügt.. Vielleicht interessiert's dich ja.

[Codehunter]

Zitat von EgonHugeist:

Hallo Cody,

schau da mal rein: https://zeoslib.sourceforge.io/viewt...?f=50&t=129484 ich habe for Zeos8 BatchArray bindings auf dem Component-Layer hinzugefügt.. Vielleicht interessiert's dich ja.

Das ist jetzt ein seltsamer Zufall. Obwohl das Thema schon eine Weile zurück liegt, habe ich just gestern Abend das Projekt von damals wieder ausgebuddelt. Zwischenzeitlich habe ich in anderen Projekten ebenfalls an dem Problem gearbeitet.

Grundsätzlich ist Firebird 2.5 nicht unbedingt ein Glanzstück was Performance angeht. Einmal scheint der Netzwerk-Stack nicht die Wurst vom Brot zu ziehen und andererseits nutzt die alte Architektur moderne CPUs nicht allzu effizient. Daneben können Queries auch nicht beliebig groß werden sondern sind IMHO auf 1024 Bytes begrenzt. In FB 3.0 wurde das auch nur minimal angehoben und erst in der kommenden 4.0 soll es dann endlich auf "unbegrenzt" große Queries gebracht werden. Kannst du mit ZEOS eigentlich schon die aktuelle FB 4.0 konnektieren?

Anhand deines Beispiels aus dem Link: Query.Params[0].AsBooleans[1] := True; könntest du evtl. mal ein Beispiel-Query zeigen, wie das anzuwenden ist?