Ado Performance steigern

[Dejan Vu]

Nee, wir sind vom Thema abgekommen. Die Auslassungen über BULK INSERT haben nichts mit den Performancemessungen zu tun.

[EgonHugeist]

Bin von der Arbeit zurück..

Zitat von Dejan Vu:

Nee, wir sind vom Thema abgekommen. Die Auslassungen über BULK INSERT haben nichts mit den Performancemessungen zu tun.

Das ist vollkommen richtig. Auch MSSQL spielt hierbei keine Rolle. Ich könnte den Provider tauschen, auf Oracle, MSAccess, Jet oder oder oder. Auch die Anzahl der Records. Die Kluft bleibt spürbar die gleiche! Sie variiert nur ein wenig. Worst case wäre die Anzahl der Inserts zu erhöhen und dann noch LOB's hinzuzufügen, dann wird's wirklich richtig übel. 5000 sind eigentlich nichts, right?!

MSSQL oder mein Kommentar im Eingangs-Thread waren ja nur der sportliche Ansporn mal etwas tiefer zu graben, sich mit ADO, wie es funktioniert und worauf es letztentlich BASIERT mal auseinander zu setzten, einen Code aufzusetzten um mal zu schauen, was da sooo geht. Und es geht einiges.

Nochmal BULK, Provider, oder der gleichen sind hierbei außen vor die Zahlen sind im weitesten Sinne "Best-Case", wenn man so will, und für mich ein dringender Indikator für "Das kann so nicht stehen bleiben". Würde ich es so akzeptieren, hieße es den Kofferraum zu öffnen und zu schauen, wie viel Heu zu den anderen Türen reinschieben kann, ohne mir um gewisse veränderte oder veränderbare Umstände Gedanken zu machen.

Mir ist mir die Kluft einfach zu groß. In dem besagten Handbuch finde ich keine gelisteten Properties der Objekte, mehr noch der Autor verweist immer wieder darauf, das er in all seinen Jahren bei MS, nie geänderte Props. gesehen hat. Er rät sogar davon ab, diese zu verändern. Kein Kommentar weshalb.. Einfach in den Raum gestellt.

Was aber nicht heißen soll, das man es nicht macht

Darum wiederhole ich die Frage an den Fundus der DP:

Was kann man tun? Hat jemand Erfahrungen mit veränderten Einstellungen von ADO?
Kann man das Default Verhalten von ADO in irgend einer Weise *push*en?

Michael

P.s:
Noch schlimmer wird es erst beim lesen der Daten, wenn man sich http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx mal vollkommen durchliest, und sich den Weg der Daten zurück an den "consumer" via ADO und am Besten noch mit Performance Drop des TDataSet vorstellt.

Edit und alle sub-links wie: http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

2. Edit:
Bernhard, das "clonen" des insert Stmts und die gleichzeitige Ausführung des mehrfach Inserts habe ich vorher auch schon getestet. Abgesehen davon, das es möglicher Weise nicht von allen Ole-Anbietern unterstützt wird, hat es mit ADO eigentlich keine spürbaren Erfolge gebracht. Den Versuch habe ich auch wieder bei Seite gelegt.

[EgonHugeist]

Gesundes Neues!

Ich wollte das neue Jahr mal nutzen und das Thema anschieben. *Push, Push* Falls irgend jemand 'ne Ahnung hat?!

Da mich das nicht in Ruhe gelassen hat, habe ich mal in ein paar freien Tagen ein neues Zeos-Protokol "OleDB" geschrieben. Nativer Zugriff via OleDB COM-Objects auf MSSQL(derzeit). Vollständig ohne ADO. Zeos-7.3 Siehe: Hier

Mal für euch zum Vergleich, was bei den Benchmark Tests (Beschreibung mit Resultaten(MSSQL fehlt da noch) Hier) heraus kam:

Code:

{
  "Engine": "ZEOS MSSQL ADO-OLEDB",
  "CreateTableTime": "279.16ms",
  "NumberOfElements": 5000,
  "InsertTime": "862.34ms",
  "InsertRate": 5798,
  "InsertBatchTime": "598.49ms",
  "InsertBatchRate": 8354,
  "InsertTransactionTime": "456.03ms",
  "InsertTransactionRate": 10964,
  "InsertBatchTransactionTime": "146.33ms",
  "InsertBatchTransactionRate": 34168,
  "ReadOneByOneTime": "97.41s",
  "ReadOneByOneRate": 51,
  "ReadAllVirtualTime": "146.62ms",
  "ReadAllVirtualRate": 34100,
  "ReadAllDirectTime": "120.59ms",
  "ReadAllDirectRate": 41462,
  "ClientCloseTime": "7.29ms"
}
{
  "Engine": "ZEOS MSSQL OLEDB(SQLOLEDB)",
  "CreateTableTime": "22.25ms",
  "NumberOfElements": 5000,
  "InsertTime": "520.75ms",
  "InsertRate": 9601,
  "InsertBatchTime": "97.36ms",
  "InsertBatchRate": 51354,
  "InsertTransactionTime": "517.12ms",
  "InsertTransactionRate": 9668,
  "InsertBatchTransactionTime": "98.50ms",
  "InsertBatchTransactionRate": 50757,
  "ReadOneByOneTime": "713.98ms",
  "ReadOneByOneRate": 7002,
  "ReadAllVirtualTime": "30.65ms",
  "ReadAllVirtualRate": 163084,
  "ReadAllDirectTime": "18.63ms",
  "ReadAllDirectRate": 268326,
  "ClientCloseTime": "6.29ms"
}
{
  "Engine": "ZEOS MSSQL OLEDB(SQLNCLI11)",
  "CreateTableTime": "117.20ms",
  "NumberOfElements": 5000,
  "InsertTime": "545.12ms",
  "InsertRate": 9172,
  "InsertBatchTime": "93.04ms",
  "InsertBatchRate": 53738,
  "InsertTransactionTime": "549.59ms",
  "InsertTransactionRate": 9097,
  "InsertBatchTransactionTime": "94.09ms",
  "InsertBatchTransactionRate": 53135,
  "ReadOneByOneTime": "822.99ms",
  "ReadOneByOneRate": 6075,
  "ReadAllVirtualTime": "30.96ms",
  "ReadAllVirtualRate": 161451,
  "ReadAllDirectTime": "19.35ms",
  "ReadAllDirectRate": 258384,
  "ClientCloseTime": "6.59ms"
}

@Dejan

wenn ich mir das mal so anschaue, liegt MSSQL gar nicht so weit von FB entfernt mit den Insert-Raten. Scheint mir eher ein ADO-Problem zu sein.. Oder ich stell mich dusselig an.. Ich habe die Anzahl der Records auch mal auf 100.000 erhöht, doch der rechnerische Durchschitt bleibt so ziehmlich der Gleiche.

@all
Also ich würde mich freuen, wenn ich ADO noch ein wenig anschubsen könnten. Das kann doch wirklich nicht alles sein

Grüße, Michael

[Dejan Vu]

Zitat von EgonHugeist:

Ich habe die Anzahl der Records auch mal auf 100.000 erhöht, doch der rechnerische Durchschitt bleibt so ziehmlich der Gleiche.

Was ist daran ? Ob ich 1000x messe oder 100.000x ist für den Durchschnitt ziemlich egal. Ob ich nun 10km oder 1000km weit mit 50km/h fahre, ist egal. Es bleiben 50km/h.

Blöde Frage (zu faul zum Blättern): Nehmen wir an, Zeos wäre lahm. Wie sieht es mit reinem ADO aus?

[EgonHugeist]

Dekile, Ja ist ne blöde Frage. Sei mal so gut und schau mal den Eingangs-Thread an.
Diese Tests umgehen ja schon mal alle TDataSet-Performance Verlußte. Somit "reines ADO" Oder eine Automarke deiner Wahl.

Goggle doch mal ein wenig und du wirst schnell festellen, ADO oder "reines ADO" setzt auf OleDB COM Objekten auf. Ist aber quasie eine Zwischen-Schicht, wie Sir Rufo es anmerkte. ADO macht alles schön einfach für den End-user. Persönlich finde ich die Idee, eine Zwischenschicht mit einer weiteren TDataSet-Zwischenschicht zu koppeln etwa wie eine Reise um Deutschland um ins Nachbardorf zu fahren (du wirst es verstehen Bin mir sicher)...

Ok lasse mich darauf ein: Zeos wäre angenommen langsam.
Nun nehmen wir eine Klasse mit diversen abstacten Proceduren um Daten zu senden und wieder zu holen.
Schreibe zwei Descendants, welche overrides zur Verfügung stellen, um dieses eben mit ADO oder mit OleDB zu machen.
Für die ADO-Klasse wirst du, sagen wir, 1.000 Zeilen brauchen, um das Gröbste abzudecken.
Für OleDB sind es wohl eher 10.000 oder mehr.

Rahmen-Bedingungen, wie du die Daten reinschaufelst und am Ende wieder raus bekommst sind die Gleichen, da du nur die Objekt/Klassen zur Verfügung hast, welche vom jeweiligen Provider unterstützt werden. Hupt da was? Könnten wir zum Thema zurück fahren?

[Dejan Vu]

Zitat von EgonHugeist:

Dekile, Ja ist ne blöde Frage...Hupt da was? Könnten wir zum Thema zurück fahren?

Wer ist Dekile, danke für die Blumen, es hupt nichts, mir egal.

Es ist Dein Problem, nicht meins, also wieso erwartest Du von *mir*, zu googeln, zu blättern, zu programmieren oder zu hupen. Piept da was bei Dir? Du willst, das wir dir helfen, vergiss das nicht.

Noch ein Tipp (falls es Deine Attitude zulässt): Fasse deine Ergebnisse doch zu einer Tabelle zusammen. Das ist besser lesbar. Und übersichtlicher. Grenze das Problem ein. Geht es Dir um die Batch-Performance oder um eine Erklärung des Overheads?

Viel Erfolg.

Ein Tipp: Schau Dir mal die SQL-Statements an, die die einzelnen Provider erzeugen.

[jobo]

Zitat von Dejan Vu:

Ob ich nun 10km oder 1000km weit mit 50km/h fahre, ist egal. Es bleiben 50km/h.

Ich halte eine Varianz der Menge für sehr sinnvoll. Je kleiner die Stichprobe, desto mehr Effekte können das Ergebnis verfälschen. Je größer die Menge, desto "stabiler" sollte der Durchschnitt werden.
Dein Satz oben zum 50 km/h Durchschnitt ist für sich genommen sinnfrei und trifft nebenbei die Messsituation nicht.

[EgonHugeist]

Zitat von Dejan Vu:

Zitat von EgonHugeist:

Dekile, Ja ist ne blöde Frage...Hupt da was? Könnten wir zum Thema zurück fahren?

Wer ist Dekile, danke für die Blumen, es hupt nichts, mir egal.

Es ist Dein Problem, nicht meins, also wieso erwartest Du von *mir*, zu googeln, zu blättern, zu programmieren oder zu hupen. Piept da was bei Dir? Du willst, das wir dir helfen, vergiss das nicht.

Noch ein Tipp (falls es Deine Attitude zulässt): Fasse deine Ergebnisse doch zu einer Tabelle zusammen. Das ist besser lesbar. Und übersichtlicher. Grenze das Problem ein. Geht es Dir um die Batch-Performance oder um eine Erklärung des Overheads?

Viel Erfolg.

Ein Tipp: Schau Dir mal die SQL-Statements an, die die einzelnen Provider erzeugen.

"Dekile" ist soweit mir bekannt die serbo-kroatische Verkleinerung von Dejan und bezogen auf dein "Ramba-Zamba"-Bild.

Dejan, ich schätze dich sehr in diesem Forum. Du hast eine gewisse Beharrlichkeit und kannst mit Lösungsansetzen tatsächlich weiter helfen. Auffällig ist deine sarkastische Art, deren zu Folge, ich der Meinung gewesen bin du kannst mit 'nem Echo umgehen. Permanente "Auto-Vergleiche" helfen mir halt nicht weiter und sind ab einem gewissen Punkt nervig. Wollte dir mit meiner minimal sarkastischen "Light" Version nicht auf die Füße treten.

Als ehemaliger Ringer, lernte ich einstecken und austeilen, doch es geziehmt sich auch folgendes: Entschuldige, Dejan. Bleiben wir doch einfach mal beim Thema und sperren die Garage zu ? Handshake!?

Sicher ist es "ein" Problem, doch eigentlich nicht meines. Ich mache das just for fun. Zeos ist ein Hobby-Code für mich.

Die beigefügten Ergebnisse sind "copy & paste" vom Synopse Test. Drei Blöcke miteinander zu Vergleichen sollte auch so noch recht lesbar sein.
Leslicher ist das dann hier
Doch wie voran bemerkt, fehlt da MSSQL in der Liste...

Overhead? Eingrenzen? Sind die Ergebnisse nicht selbsterklärend?

Das Anschauen der stmt... Weiß nicht, ob ich dir folgen kann. Der Server ist immer der Gleiche. Nur die Art des Zugriffs ist geändert. Somit würde ich davon ausgehen, das sich die Provider mit dem Stmt auch gleich Verhalten sollten, oder lieg ich falsch? Welches Szenario wäre denkbar? Ist keine Jet-Engine, welche die selects zerlegt und das holen der Daten improvisiert..

@jobo
Jup! Um Performance-"Wellen" zu deckeln habe ich das einfach mal gemacht. Das weiteren wäre es möglich das ADO z.B. im Hintergrund eine gewisse Datenmenge vorbereitet, welche dann schnellst möglich dem "consumer" zur Verfügung gestellt wird(Sonderbar, auf welche Theorien man kommt...). Aber eben erst nach Vorbereitung. Somit war das Erhöhen der Mess-Daten grundsätzlich relevant führ mich.

Michael