Performance vom DataSet

[Prior Michael]

Hallo,

z. Z. schreibe ich eine 3-schichitige Anwendung von Delphi 7 und ADO nach .NET (C#) und ADO.NET um und setze den MS SQL Server ein. Der Zugriff auf die Datenbank erfolgt über Stored Procedure.

Unter WIN32 waren die Zugriffzeiten des Clienten auf das transportierte RecordSet akzeptabel (ca. 150 ms); unter .NET steigt die Zugriffszeit auf das transportierte DataSet auf das 9-fache (ca. 1200 ms).

Das DataSet selbst ist in ca. 70 ms gefüllt; die Zeit scheint auf dem Weg vom Server (Enterprise Service) zum Clienten verbummelt zu werden.

Alles läuft z. Z. auf einem System. Hat jemand eine Idee?

Vielen Dank!

[Andreas Kosch]

Hallo,

wie viele Datensätze sind im DataSet? Im .NET Framework 1.x wird der DataSet-Inhalt immer nur als XML über die Leitung geschickt, so dass im Vergleich zum ADO-Recordset eine vielfache Datenmenge transportiert werden muss. Erst im .NET Framework 2.0 stellt das DataSet eine Eigenschaft zur Verfügung, um auf die binäre Serialisierung zu schalten.
<br>
Bis dahin gibt es nur zwei Möglichkeiten, wenn die "alte" Übertragungsleistung benötigt wird: <br>
a) Ein eigener Nachfolger von DataSet implementiert die binäre Serialisierung, oder
<br>
b) man verpackt die Daten auf dem Server (.NET Enterprise Service) als ADO-Recordset-Objekt und mischt dies erst im .NET-Client über <i>OleDbDataAdapter</i> in eine DataSet-Instanz ein.
<br>
Im <i>dot.net magazin</i> Heft 09.04 habe ich u.a. beide Alternativen in einem Beispielprojekt gegenübergestellt und die Leistungsunterschiede zum originalen DataSet getrennt für das LAN (100 MB/s) und WAN (256 kB/s) verglichen. Im dortigen Beispielprojekt ist auch die eigene DataSet-Nachfolgerklasse für die binäre Serialisierung zu finden.
<br>
Auch bei der Geschwindigkeit, wie eine <b>DataTable</b>-Instanz im DataSet eine größere Datenmenge laden kann, legt das .NET Framework 2.0 spürbar zu. Während ADO.NET 1.1 für 200.000 lokale Datensätze noch 47 Sekunden braucht, ist ADO.NET 2.0 bereits nach 16 Sekunden fertig. Der Grund dafür liegt darin, dass einige Teile der DataTable-Klasse (u.a. die Index-Generierung) von Microsoft im .NET Framework 2.0 völlig neu geschrieben wurden

[Prior Michael]

Hallo Herr Kosch,

in dem hier angewendeten Beispiel sind in der Tabelle ca. 2500 Datensätze. Das ganze ist als Versuch gedacht, um die Performance des DataSet im Vergleich mit dem RecordSet zu testen.

Es gibt in der Anwendung jedoch Abfragen, die bis zu 20000 Datensätze zurückliefern können; es handelt sich um eine Produktdatenbank in der z. B. die Abfrage die Seriennummern über einen bestimmten Zeitraum zurückliefert.

Ich werden den Vorschlag b. angehen und das Ganze in einem RecordSet auf die Reise schicken. Damit habe ich dann auch noch die Möglichkeit, daß die "alten" WIN32 Clienten funktionieren u. somit die komplette Anwendung Schritt für Schritt nach .NET bringe; was auch angedacht war.

Ich muß jetzt "nur" noch herausfinden, wie man am einfachsten (Performance!) aus dem DataSet ein RecordSet macht? Ich möchte allerdings, wenn es sich vermeiden läßt, keine 2 Datenbankverbindung unter ADO aufbauen.

Zudem werde ich mir das dot.net magazin Heft 09.04 besorgen.

Vielen Dank

[Andreas Kosch]

Hallo,
&gt;...keine 2 Datenbankverbindung unter ADO aufbauen.
Warum diese Selbstkasteiung? Sowohl ADO.NET als auch ADO laufen im Fall des Zugriffs auf den MS SQL Server über einen Datenbankverbindungs-Pool, so dass ein ständiges Öffnen/Schließen von zwei Verbindungswegen keine Nachteile hat. Ich würde das ADO-Recordset über den "alten" ADO-Weg (Connection, Command) mit Daten füllen und dann zum Client schicken. Trotz COM-Interop (.NET bindet "altes" COM-Objekt von ADO ein) ist das am Ende schneller als der reine .NET-Weg über das DataSet