Performance-Unterschied

[MPirnstill]

Hallo Leute!

Ich weiß nicht, ob ihr es wußtet, aber ich könnte in diesem Forum falsch sein. Aber ich versuch es eben einmal.

Ich habe da ein etwas "älteres" Problem. Älter, da es sich um eine Delhpi 2 Enterprise Anwendung handelt mit der ich auf einen
MS-SQL-Server 6.5 zugreife. Jetzt wurde der SQL-Server gegen einen MS-SQL-Server 2000 ausgetauscht, was auch mit kleinen Problemchen ganz gut klappte. Im Rahmen dieser Umstellung soll die Anwendung jetzt über ODBC statt BDE - SQLLinks zugreifen. Heutzutage ist ODBC ja auch schneller als die BDE.

Mein Problem dabei ist folgendes:
Auf meinem Entwickulungssystem (Pentium 4, 3 Ghz, 500 MB Ram) funktioniert das wunder-schnuffig. Alles blitzschnell. Eine Sekunde um einen Erfassungsdialog zu öffnen. Auf dem Rechner des Anwenders (gleiches System wie mein Entwicklungsrechner) benötigt die gleiche EXE 17 Sekunden um einen Erfassungsdialog zu öffnen. Beim Start der MDI-Anwendung wäre dies nicht so wild (passiert ja nur zu beginn), aber beim Öffnen eines Erfassungsdialogs ist das schon sehr lästig, vor allem wenn die Anwender vorher schnelleres gewöhnt sind. Da es die gleiche EXE ist, vermute ich das ich da noch etwas mitinstallieren muß, weiß aber nicht was.
Die Installation habe ich mit InstallShield 3.5 SP 4 (von der Delphi 7 Version) erstellt. Bei den Merge-Modulen habe die BDE-ENT, BDERTL, BaseRTL sowie DatabaseRTL angekreuzt. Dementsprechnd ist die BDE 5.1 mitinstalliert. Ach ja, irgendwie will die Anwendung immer noch die BDE initialisieren, obwohl ich beim TDatabase-Objekt den Zugriff auf ODBC umgeleitet habe.

Bin für jegliche Hinweise sehr dankbar.

Micha

[Bernhard Geyer]

Du hast einen großen Fehler bei der Umstellung gemacht: Du gehst über ODBC mittels TDatabase/TTable/TQuery. Und damit bist du die BDE nicht los, da TDatabase/TTable/TQuery-BDE-Basierend sind.

Wieso hast Du dein Programm nicht gleich auf ADO(Express) umgestellt. Ist ab D5 (Enterprise) bzw. D6 Pro dabei (D8 schaut es schlecht aus, aber D2005 ist es wieder dabei).

Damit wärst Du die BDE und auch gleich die ODBC-Schnittstelle auch los. Alles was Du benötigst ist eine halbwegs aktuelle ADO-Installation (sollte praktisch auf fast jeden halbwegs modernen Rechner der Falls sein). Ab 2000 ist es sowieso gleich in einer passenden Version dabei. Und ebenfalls setzt du ziemlich direkt auf die native Schnittstelle des MS SQL-Servers 7/2000 auf.

[shmia]

Ich würde erst mal die Datenbankstruktur unter die Lupe nehmen.
Nur wenn die Datenbank sauber aufgebaut ist, kann die Performance stimmen.

• Haben alle Tabellen einem Primärschlüssel ?
• Haben alle Tabellen einen gruppierten index (Clustered Index) ?
• Sind alle Fremdschlüsselfelder indiziert ?

Zu den beiden ersten Punkten gibt es 2 nützliche Views:

SQL-Code:

CREATE VIEW dbo.vwNoPrimaryKeys
AS
SELECT name
FROM sysobjects
WHERE id NOT IN
        (SELECT b.id
      FROM sysconstraints b, sysobjects c
      WHERE c.type = 'K' AND c.id = b.constid) AND type = 'U'

SQL-Code:

CREATE VIEW dbo.vwNoClusteredIndex
AS
SELECT   name
FROM         dbo.sysobjects so
WHERE     (NOT EXISTS
                          (SELECT     si.id
                            FROM          sysindexes si
                            WHERE      indid = 1 AND si.id = so.id)) AND (type = 'U')
ORDER BY name

[Bernhard Geyer]

Ein problem mit dem Index sollte es nicht sein, da das Programm ja auf seinem Rechner (ich denke es wird die gleiche Datenbank verwendet) läuft als auch mit BDE-Links auch keine Probleme hatte.

[nieurig]

Neben der DB-Struktur ist auch sehr wichtig,
wieviele Daten beim öffnen des Formulares von
der DB abgefragt werden.

Schlimmste Version:
Tabelle öffnen und mit locate auf einen
Datensatz gehen der angezeigt wird.

Viel besser:
Beim Öffnen des Forms nur per
Select * from Tabelle where ID = ??
den anzuzeigenden Datensatz laden. Stammen
die Daten aus mehreren Tabellen dann macht
sich die DB-Struktur und besonders die Indexes
bemerkbar.

Schönen Tag noch !
Niels

[shmia]

Zitat:

Zitat von Bernhard Geyer

Ein problem mit dem Index sollte es nicht sein, da das Programm ja auf seinem Rechner (ich denke es wird die gleiche Datenbank verwendet) läuft als auch mit BDE-Links auch keine Probleme hatte.

Naja, sobald die Datenmenge etwas grösser wird ( > einige hundert Datensätze) steigt die Zugriffszeit linear bis quadratisch an, wenn nicht die richtigen Indexe angelegt wurden.

Abfragen, die auf der Testdatenbank nur 0,1 Sekunden brauchen, können dann in der Praxis beim Kunden mehrere Minuten bis zum Timeout-Fehler brauchen. :pale:

Dies trifft auch dann zu, wenn man den Fehler, den nieurig bschrieben hat, begangen hat.
In diesem Fall kann auch das Netzwerk zum Flaschenhals werden. (z.B. Zuhause 100MBit, beim Kunde nur 10 Mbit)

[Bernhard Geyer]

Zitat:

Zitat von shmia

Naja, sobald die Datenmenge etwas grösser wird ( > einige hundert Datensätze) steigt die Zugriffszeit linear bis quadratisch an, wenn nicht die richtigen Indexe angelegt wurden.

Abfragen, die auf der Testdatenbank nur 0,1 Sekunden brauchen, können dann in der Praxis beim Kunden mehrere Minuten bis zum Timeout-Fehler brauchen. :pale:

Dies trifft auch dann zu, wenn man den Fehler, den nieurig bschrieben hat, begangen hat.
In diesem Fall kann auch das Netzwerk zum Flaschenhals werden. (z.B. Zuhause 100MBit, beim Kunde nur 10 Mbit)

Lassen wir Micha mal uns weitere Infos geben, bevor wir hier weiter in Spekulationen uns auslassen.
Und diese "Indexproblem" kenn ich. Hab selbst DB's im Einsatz die mit Datenmengen > 4 GB zurechtkommen müssen.

Fragen an Micha:

- Werden auf dem Entwicklungs-PC und dem Problem-PC mit der gleichen (Produktiv-)Datenbank verbunden?
- Wenn das BDE-Links-Programm auf dem Problem-PC läuft, sind die Wartezeiten ähnlich?

[MPirnstill]

Vielen Dank für die schnellen Antworten! Super!

Zitat:

Zitat von Bernhard Geyer

Du hast einen großen Fehler bei der Umstellung gemacht: Du gehst über ODBC mittels TDatabase/TTable/TQuery. Und damit bist du die BDE nicht los, da TDatabase/TTable/TQuery-BDE-Basierend sind.

Wieso hast Du dein Programm nicht gleich auf ADO(Express) umgestellt. Ist ab D5 (Enterprise) bzw. D6 Pro dabei (D8 schaut es schlecht aus, aber D2005 ist es wieder dabei).

Damit wärst Du die BDE und auch gleich die ODBC-Schnittstelle auch los. Alles was Du benötigst ist eine halbwegs aktuelle ADO-Installation (sollte praktisch auf fast jeden halbwegs modernen Rechner der Falls sein). Ab 2000 ist es sowieso gleich in einer passenden Version dabei. Und ebenfalls setzt du ziemlich direkt auf die native Schnittstelle des MS SQL-Servers 7/2000 auf.

Ich vergaß zu erwähnen, das dies eine Notlösung sein soll, da ich ich die Komplettumstellung der Anwendung auf WEB nicht termingerecht fertig bekomme, wurde beschlossen vorerst die alte Anwendung mit geringem Aufwand anzupassen.
Deshalb bin ich bei Delphi 2 geblieben und habe nicht auf einer höheren Version compiliert. Außerdem hätte ich bei einer höheren Version alle Quickreports neu machen müssen, da diese ja nicht mehr kompatibel wären. Aber sonst wäre das eine gute Idee mit ADO. Wären die TTables den einfach durch die ADOTables ersetzbar?

Zitat:

Zitat von shmia

Haben alle Tabellen einem Primärschlüssel ?

Haben alle Tabellen einen gruppierten index (Clustered Index) ?

Sind alle Fremdschlüsselfelder indiziert ?

Die Tabellen haben alle einen Primärschlüssel. Aber vielen Dank für die Views für die System-tabellen. Die finde ich gut.

Zitat:

Zitat von nieurig

Schlimmste Version:
Tabelle öffnen und mit locate auf einen
Datensatz gehen der angezeigt wird.

Ich muß leider eingestehen, das es so ist, jedoch ohne locate, da einfach der erste Datensatz angezeigt wird.
Vielleicht sollte ich, da es wie gesagt eine Notlösung ist, hier ansetzen und einfach erstmal den ersten Datensatz holen um der Anwendung Zeit zu verschaffen den Rest ranzuschaffen.


Mehr gleich zu Bernhards Fragen. Will erstmal diese Antwort los werden. Habe die schon einmal verloren.

[MPirnstill]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von shmia

Naja, sobald die Datenmenge etwas grösser wird ( > einige hundert Datensätze) steigt die Zugriffszeit linear bis quadratisch an, wenn nicht die richtigen Indexe angelegt wurden.

Abfragen, die auf der Testdatenbank nur 0,1 Sekunden brauchen, können dann in der Praxis beim Kunden mehrere Minuten bis zum Timeout-Fehler brauchen. :pale:

Dies trifft auch dann zu, wenn man den Fehler, den nieurig bschrieben hat, begangen hat.
In diesem Fall kann auch das Netzwerk zum Flaschenhals werden. (z.B. Zuhause 100MBit, beim Kunde nur 10 Mbit)

Lassen wir Micha mal uns weitere Infos geben, bevor wir hier weiter in Spekulationen uns auslassen.
Und diese "Indexproblem" kenn ich. Hab selbst DB's im Einsatz die mit Datenmengen > 4 GB zurechtkommen müssen.

Fragen an Micha:

- Werden auf dem Entwicklungs-PC und dem Problem-PC mit der gleichen (Produktiv-)Datenbank verbunden?
- Wenn das BDE-Links-Programm auf dem Problem-PC läuft, sind die Wartezeiten ähnlich?

Vom Umfang her ist die Produktiv-Datenbank mit der Test-Datenbank identisch. Allerdings habe ich eine extra SQL-Server zum testen. Auf dem neuen Produktiv-Server ist aber noch kein weiterer Anwender drauf, da ich das ja erst noch teste.
So jetzt der Knack-Punkt. Ich habe mit meinem Test-SQL-Server eine 1,0 GBit Verbindung und die Verbindung vom Test-Rechner zum Produktiv-Server ist 10 MBit glaub ich. Unser Admin sagte, daß sei in Ordnung. Liegt es jetzt doch an der Netzverbindung?

Zu BDE-Links auf dem Test-Rechner. Das muß ich mit dem neuen Produktiv-Server erst noch ausprobieren. Beim alten SQL-Server 6.5 lief es über BDE-Links auf jeden Fall schneller.

Micha

[Bernhard Geyer]

Zitat:

Zitat von MPirnstill

So jetzt der Knack-Punkt. Ich habe mit meinem Test-SQL-Server eine 1,0 GBit Verbindung und die Verbindung vom Test-Rechner zum Produktiv-Server ist 10 MBit glaub ich. Unser Admin sagte, daß sei in Ordnung. Liegt es jetzt doch an der Netzverbindung?

Dann könnte es schon sein das Du dein Programm optimieren musst.

Zitat:

Zitat von MPirnstill

Zu BDE-Links auf dem Test-Rechner. Das muß ich mit dem neuen Produktiv-Server erst noch ausprobieren. Beim alten SQL-Server 6.5 lief es über BDE-Links auf jeden Fall schneller.

Teilweise könnte es sein das die alten Links öfters den Vorteil von serverseitigen Cursern ausnutzen konnte wo der Zugriff über ODBC nur einen clientseitigen Curser liefert. Und da muß die gesamte Datenmenge zum Client übertragen werden bevor sie angezeigt werden kann.

[MPirnstill]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von MPirnstill

So jetzt der Knack-Punkt. Ich habe mit meinem Test-SQL-Server eine 1,0 GBit Verbindung und die Verbindung vom Test-Rechner zum Produktiv-Server ist 10 MBit glaub ich. Unser Admin sagte, daß sei in Ordnung. Liegt es jetzt doch an der Netzverbindung?

Dann könnte es schon sein das Du dein Programm optimieren musst.

Ich bin schon am gucken, wo ich den Zugriff optimieren könnte. Gab es eigentlich damals bei D2 schon so eine Einstellung, daß die Anwendung die ersten Datensätze ruhig schon zeigen soll, während die Anwendung den Rest noch lädt? Weil sonst muß ich mal sehen wie das mit Threads so funktioniert. Habe ich nämlich noch nie benutzt.

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von MPirnstill

Zu BDE-Links auf dem Test-Rechner. Das muß ich mit dem neuen Produktiv-Server erst noch ausprobieren. Beim alten SQL-Server 6.5 lief es über BDE-Links auf jeden Fall schneller.

Teilweise könnte es sein das die alten Links öfters den Vorteil von serverseitigen Cursern ausnutzen konnte wo der Zugriff über ODBC nur einen clientseitigen Curser liefert. Und da muß die gesamte Datenmenge zum Client übertragen werden bevor sie angezeigt werden kann.

Also ich habe noch mal die ursprüngliche Anwendung (über BDE-Links) auf den neuen SQL-Server 2000, welcher nicht hier lokal ist, umgelenkt. Da braucht der Aufruf des Erfassungdialogs immerhin auch nur 3 Sekunden anstatt 17 Sekunden über die ODBC-Verbindung.

Übrigens gleich noch eine Frage für meine neue WEB-Anwendung, welche ich mit D2005 erstelle. Du scheinst ja mit D2005 ganz gut klar zu kommen. Das läuft bei mir so .....-langsam und hängt meist nach einigen Testdurchläufen sogar auf, da der Speicher absolut dicht ist. Aber darauf wollte ich jetzt garnicht hinaus, sondern wie ich unter D2005 die Datenanbindung am besten realisiere? SQLConnection? BDPConnnection? Ich habe mal im Internet eine Aufstellung gesehen, da war die SQLConnection am schnellsten.

mit sonnigen (ups alles bewölkt, wenn ich rausschau) Grüßen

Micha

[Bernhard Geyer]

Zitat:

Zitat von MPirnstill

Ich bin schon am gucken, wo ich den Zugriff optimieren könnte. Gab es eigentlich damals bei D2 schon so eine Einstellung, daß die Anwendung die ersten Datensätze ruhig schon zeigen soll, während die Anwendung den Rest noch lädt? Weil sonst muß ich mal sehen wie das mit Threads so funktioniert. Habe ich nämlich noch nie benutzt.

Die Anwendung läd nicht im Hintergrund die Daten weiter (würde teilweise mit ADO gehen) sondern die Daten werden nur "Häpchenweise" bei Bedarf vom Server abgefragt:

Vorteil: Schnelle Antwortzeit
Nachteil: Hohe Serverbelastung

Zitat:

Zitat von MPirnstill

Übrigens gleich noch eine Frage für meine neue WEB-Anwendung, welche ich mit D2005 erstelle. Du scheinst ja mit D2005 ganz gut klar zu kommen.

Ich habe zwar D2005 aber ohne SP2 bleibe ich noch bei D6.

Zitat:

Zitat von MPirnstill

Aber darauf wollte ich jetzt garnicht hinaus, sondern wie ich unter D2005 die Datenanbindung am besten realisiere? SQLConnection? BDPConnnection? Ich habe mal im Internet eine Aufstellung gesehen, da war die SQLConnection am schnellsten.

Ich würde BDP nicht verwenden, da man hier wieder in eine Zusätzliche unnötige Herstellerabhängikeit kommt (Neben den noch in BDP vorhanden unzulänglichkeiten). Nimm lieber direkt die Komponenten die M$ mitliefert.

[MPirnstill]

Zitat:

Zitat von Bernhard Geyer

Zitat:

Zitat von MPirnstill

Übrigens gleich noch eine Frage für meine neue WEB-Anwendung, welche ich mit D2005 erstelle. Du scheinst ja mit D2005 ganz gut klar zu kommen.

Ich habe zwar D2005 aber ohne SP2 bleibe ich noch bei D6.

Hoffentlich schweife ich hier nich zu weit vom Thema "Performance-Unterschied" ab. Aber schreibst du mit D6 auch Web-Anwendungen? Ist nämlich folgendes. Ich soll diese Client/Server-Anwendung als Web-Lösung neu erstellen. Ich habe aber vorher noch keine Web-Anwendung geschrieben. Und dann noch dies neue Konzept bei ADO.NET. Ich habe noch nicht den richtigen Durchblick nach welchem Schema man diese Web-Dialog aufbaut. Und wenn was schief läuft, weiß ich immer nicht, ob es an mir oder an Delphi liegt. Okay, ich hab schon ein, zwei einfache Dialog erstellt, aber sowie es komplizierter wird, krieg ich es nicht mehr gebacken. Egal, gehört hier nicht her, ich bin nur Einzelkämpfer (Entwcklungstechnisch) und habe keinen mit dem ich die Probleme durchsprechen kann, deshalb verfalle ich manchmal ins labern.

Auf alle Fälle vielen Dank für die Hilfe soweit.

Micha

[Bernhard Geyer]

Zitat:

Zitat von MPirnstill

Hoffentlich schweife ich hier nich zu weit vom Thema "Performance-Unterschied" ab. Aber schreibst du mit D6 auch Web-Anwendungen?

Nein, nur Win32-Anwendungen. Für Web wird bei uns Java verwendet. Ist wirklich BS-Unabhängig (gegenübe .NET, das hier erst am Anfang mit MONO steht) und auch schon auf komischten Servern am laufen.