ADO Performance

[Niels Költer]

Hallo,

wir haben eine Anwendung von Pervasive SQL mit native Zugriff umgestellt auf Microsoft SQL über ADO.

Mit einem kleinen Performance Test Programm lassen wir in einer Transaction ca. 10 Selects (jeweils 1 Record als Ergebnis), 1 Insert und 1 Update laufen.

Mit nativem Zugriff auf Pervasive SQL haben wir so 290 Transaktionen pro Sekunden pro Client hinbekommen, der Client hatte dabei nur eine geringe CPU Auslastung.

Mit dem Zugriff über ADO auf MS-SQL Server ( und auch auf Pervasive SQL) erhalten wir so nur noch ca. 5 Transaktionen pro Sekunde. Außerdem liegt die CPU Auslastung des Clients bei nahezu 100 %.

Kann uns jemand evtl. einen Tip geben, warum die CPU Auslastung bei ADO so hoch ist und warum der Performance unter ADO so schlecht ist.

Danke
Niels

[Bernhard Geyer]

1, Die ADOExpress/dbGo-Wrapper von Borland bremsen da sie z.B. bei jedem Open-Befehl versucht zu erkenne ob AutoInc-Felder vorhanden sind.

2, Ohne genauen Code können wir nicht erkennen ob du einfach nur ungünstigen Code/Einstellungen verwendest. z.B. sollte man bei MS-SQL-Server Clientseitige Curser bei den Selects verhintern. Wie wird das Insert/Update durchgeführt (optimiertes Queries) oder Recordset mit .Edit und .Post?

Selbst haben wird (ohne ADOExpress) absolut keine Probleme mit MS-SQL-Server und erreichen genauso hohe Geschindigkeiten wie bei Oracle oder MySQL. A. Kosch hat schon des öfteren im Forum gezeigt wie man mit ADO (ohne Wrapper) sehr schnell Zugriffe auf den MS-SQL-Server ermöglicht

[Niels Költer]

Was heißt keine Probleme?

wir haben das Problem, das ein einzelner Client möglichst rasch die Antwort erhalten soll.

Das heißt wir möchten einzelne Datensätze über Primary Index (oder einem anderen Index) direkt einladen, in unserem Programm Voraussetzungen überprüfen und dann den Datensatz evtl. verändert wieder abspeichern.

Mit Pervasive SQL konnten wir so eben pro Client 2500 einzelne Datensätze pro Sekunde seriell hintereinander abfragen.
Mit SQL-Server und ADO kommen wir gerade mal auf 120 einzelne Datensätze pro Sekunde.

Das Problem ist die lange Antwortzeit, die jedoch nicht vom Server zu kommen scheint. Weiterhin geht die CPU- Auslastung des Clients auf 100% zu.

Komplexe Anfragen die mehrere hundert bzw. tausend Datensätze zurückgeben werden ähnlich schnell beantwortet. Hier ist die Performance des SQL-Server unter ADO sogar besser als die von Pervasive SQL unter native Zugriff.

Nur die Einzelabfragen, die wir für unsere Buchungen (OLTP-System) nun einmal brauchen, werden zu langsam beantwortet

[Bernhard Geyer]

Dann zeig doch mal etwas Code (Auch deine Komponenten-Einstellungen). Du wirst irgendeine Einstellungen falsch vornehmen. Aber Blind das Problem zu finden?

Es könnte auch sein das Netzwerkprobleme zu deinem SQL-Server existieren (Namensauflösung, Firewalls oder ähnliches)

[Mario.Noack]

Ist es ein SQL-Server und nicht die MSDE? Verändert sich das Verhalten beim Ändern des Cursors (Client bzw. Serverseitig).<p>
Mari

[Gunter Heuckeroth]

Hallo,

ich habe ein ähnliches Problem (Delphi 7, ADO, einzelne Datensätze heraussuchen, testen und ggf. ändern) und folgendes herausgefunden:
Mit dem "Locate" einer ADOQuery ist es tödlich (z.Z. Sekunden bis Datensatz gefunden, obwohl benutzte Key-Werte im Index sind).
Eine deutliche Verbesserung, aber immer noch sehr langsam ist ein erneutes "SELECT..." (Im Moment über parametrisierte Select-anweisung).
Hat jemand die Idee für eine "schnelle" Methode?

Anmerkung: Das "Locate" mit einer TAdsQuery (Advantage) is rasend schnell...

Gunte