Ado Performance steigern

[Dejan Vu]

Zitat von Bernhard Geyer:

Dann machen wir was falsch. Wir inserten Mio-Datensätze in Stunden.

Wenn die Performance reicht, nicht (steht doch auch da).

Zitat:

Zitat von Dejan Vu:

Aber weder das eine noch das Andere wird von ADO nicht unterstützt (ADO wird imho eh nicht weiterentwickelt).

Betrifft AFAIK nur den MS OLE DB Provider for SQL Server, nicht den SQL Server Native Client.

Das kann sein.

Zitat:

Zitat von Dejan Vu:

BULK INSERT bekommst Du aber mit einem einfachen ADOCommand hin.

Eigentlich schon - oder jedenfalls fast. Du kannst problemlos mehrer INSERTS zu einem einzelnen "BULK" zusammenfassen.

Nein. Äh. Ja, du kannst INSERT-Statements in einen String packen und den dann rüberschicken, das geht viel schneller (eine Transaktion vs. 1000).
Und nein: Du bekommst einen BULK INSERT nicht nur "fast", sondern vollständig hin.
Wenn Du Zugriff auf das Serververzeichnis hast, schreibst Du die Daten dort in eine Datei und führst ein BULK INSERT aus. Geht das so nicht, dann über BCP.EXE. Das liest die Daten lokal ein und bläßt sie übers Netz direkt in den Server.

Eventuell kommst Du über Delphi auch direkt an die SMO, aber da bin ich mir nicht sicher, weil das normalerweise für .NET ist. In den SMO ist ein SqlBulkCopy-Objekt.

BULK INSERT lohnt sich aber erst bei Batches > 5000 Records. Dafür dann aber mit 10k-100k Records pro Sekunde.

SELECT mit OPENROWSET ist auch noch eine Variante. Hab ich aber noch nicht probiert.

[Sir Rufo]

Wenn man die Performance der Zwischenschicht ermitteln will, dann teste ich doch nicht den BestCase, sondern den WorstCase. Allerdings ist es entscheidend, wie schnell wird dieser WorstCase ohne und mit Zwischenschicht verarbeitet. Aus dem Unterschied kann ich dann den Overhead der Zwischenschicht errechnen. Ist der Overhead unter einem Prozentsatz x, dann brauche ich mir über die Verbesserung der Zwischenschicht nicht mehr so viele Gedanken machen.

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

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