Announcement

**Bernhard Geyer** · 05.04.2000, 15:39

Evtl. mu�t Du nicht deinen Server tunen, sondern deine Client-Applikation. 80000 Datens�tze pro Stunde bedeutet 22 Datens�tze pro Sekunde, also ca. alle 45 ms ein Datensatz. Bei meiner Umgebung (SQL-Server 7.0 auf NT 4.0 mit P-III 500, 128 MB komme ich auf ca. 20 ms pro Datensatz bei Client/Server auf unterschiedlichen Rechnern)

Evtl. mu�t Du versuchen mit mehreren Threads die Daten in die Datenbank zu schreiben. Dazu ein paar Fragen um die Performance-Bremse genauer herauszufinden:

- Laufen der Client und der Server auf einer Maschine. Falls nein kann ein Test mit Client und Server auf einer Maschine durchgef�hrt werden? Ergibt sich dabei eine Steigerung der Datensatz-Rate?

- Was passiert, wenn 2 Instanzen deiner Applikation (unterschiedliche Datenbest�nde) gleichzeitig die Daten in den Server schreiben? Ist dann die Anzahl der "erledigten" Datens�tze pro Stunde pro Applikation immer noch so hoch wie mit einer Applikation? Wenn ja, dann ben�tigt die Kommuikation Client -> Server f�r jeden Datensatz eine bestimmte Zeit (z.B. f�r Validierung auf Clientseite, Serverseite, �bertragung �ber Netz) und die Performance kann durch paralles Schreiben von Datens�tzen mit Threads beschleunigt werden

**Heinz Blubber** · 05.04.2000, 18:55

Vielen Dank f�r Deine schnelle Antwort.

Ich sehe das Problem weniger in meiner Applikation oder Hardware, sondern vielmehr im Tuning von Interbase.

Zu dieser Behauptung komme ich, weil mit dBase oder Paradox etwa 5 mal mehr Datens�tze je Stunde geschrieben worden sind (auch mit mehreren Instanzen. Allerdings l��t die Perfomens bei etwa 600.000 Datens�tzen (dBase) extrem nach, soda� ich nach einer anderen Datenbank greifen mu�te.

Weiterhin verursacht Interbase, wie oben beschrieben, etwa die gleiche Last auf dem Server, egal ob eine oder mehrere Applikationen arbeiten, die Anzahl der eingef�gten Datens�tze steigt dabei nur unwesentlich.

zu Deinen Fragen: Es werden mehr Datens�tze je Sekunde eingf�gt, wenn die Applikation auf dem Server l�uft. Laufen beide Applikationen auf dem Server, sinkt die "Insertrate" extrem (von 80.000 auf etwa 50.000 Datens�tze je Stunde). Deshalb schlie�e ich auch Netzwerkprobleme aus

**Andreas Kosch** · 06.04.2000, 07:49

Hallo,

sowohl dBASE als auch Paradox kennen keine Transaktionen, ausserdem sind ISAM-Datenbanken bei dieser Aufgabe bis zu einer bestimmten Gr�sse generell schneller als SQL-Datenbanken, weil beim Massenimport der datensatzorientierte Zugriff effektiver ist.

Die interessanten Fragen beim InterBase sind 
a) Welcher Isolation Level wird verwendet (tiRepeatableRead oder tiReadCommitted)? Bei h�ufig gestarteten Transaktionen ist tiRepeatableRead effektiver.

b) Wird jeder INSERT-Vorgang in eine eigene Transaktion verpackt? Wenn ja, wird hier der Grund f�r das tr�ge Verhalten liegen.

c) Treten gleichzeitig viele kurze Transaktionen sowie eine sehr lange Transaktion (mit vielen INSERTs) auf? Kann es in dieser Umgebung zu ROLLBACKS kommen? In diesem Fall w�rde der InterBase einen SWEEP ausl�sen, wenn der konfigurierte Schwellwert f�r die Differenz zwischen OIT und OAT erreicht wird.

d) Ist f�r die InterBase-Datenbank Enable forced writes aktiviert? ("Performing forced writes ensures data integrity and safety, but will slow performance. In particular, operations which involve data modification will be slower."). Beim Massenimport von Daten kann dies deaktivert werden - da der Import im Fehlerfall wiederholt werden kann.

e) Welches Netzwerkprotokoll wird verwendet und sind Performanceunterschiede zwischen TCP/IP und NetBEUI feststellbar?
&#10

**Heinz Blubber** · 06.04.2000, 16:18

Hallo Herr Kosch,

zu Ihren Fragen:

a) Die Frage nach dem Isolationslevel kann ich erst heute abend beantworten.

b) Um eine einfache Umstellung der Software zu erreichen, habe ich weiterhin die Komponenten TDatabase und TTable verwendet. Folgende Verarbeitungslogik (vereinfacht) findet statt:

readln (seq. File) 
repeat 
Table.EditKey; 
.... 
if not Table.GotoKey then 
begin 
Table.Append 
.... 
try 
Table.Post 
except 
Table.Cancel 
end; // end try 
end; // end if 
readln (seq. File) 
until EOF (seq. File) 

ich gehe davon aus, da� ein Post ein Commit beinhaltet, weiterhin gehe ich davon aus, da� ich auf SQL umstellen sollte und im Abstand von einigen (wieviel???) Datens�tzen ein Commit setzen sollte --> Frage: wie ermittle ich das Optimum zwischen Sicherheit, Caching und Perfomenc???
Anderenseits: kann der Einsatz von Stored Procedure eine h�here Perfomec bringen?

c) Rollbacks sind fast auszuschlie�en, da maximal 2 Prozesse schreibend auf diese Tabelle zugreifen, alle anderen lediglich lesend. Nach Sch�tzungen wird es t�glich 2 Millionen Transaktionen auf die Tabelle geben, davon sind etwa 400.000 Insert

d) Enable forced writes ist aktiviert, mir fehlt etwas der Mut zur Deaktivierung.

e) Als Netzwerkprotokol wird NetBEUI verwendet, �ber TCP/IP habe ich noch keinen Versuch gestartet, wird heute noch nachgeholt

**Andreas Kosch** · 07.04.2000, 07:23

Hallo,

die Antwort b) deutet darauf hin, das der AutoCommit-Modus der BDE ausgenutzt wird. Das ist zwar f�r uns als Entwickler sehr bequem, da sich die VCL+BDE um alles k�mmert - aber in diesem konkreten Fall �berwiegen die sich daraus ergebenden Nachteile. Der AutoCommit-Modus bewirkt, das bei jedem Datensatz die folgenden Schritte ablaufen: 
1. Transaktion wird auf dem InterBase gestartet 
2. Ein Datensatz wird eingef�gt. 
3. Transaktion wird auf dem InterBase beendet. 
Das Starten einer neuen Transaktion verursacht auf jedem SQL-Server einen gewissen Aufwand, der in diesem Fall unn�tig ist.

Ich w�rde daher als erstes daf�r sorgen, das ca. 100..200 Datens�tze in einer Transaktion in die InterBase-Datenbank geschrieben werden. Da auch TTable alle Anweisungen in SQL �bersetzen muss und nur bei kleinen Ergebnismengen (d.h. Filter ist aktiv) effektiv arbeitet, ist es besser, eine TQuery vor dem Start der Schleife mit Prepare einmalig vorzubereiten. F�r jeden Datensatz m�ssen dann nur die Parameter �bergeben werden - die abgeschickte SQL-Anweisung bleibt vom Aufbau her gleich, so das ein Prepare ausreicht. In diesem Fall (Prepare wird vor der Schleife aufgerufen) bringt auch eine Stored Procedure nur geringe Performancevorteile.

Mit dem SQLMonitor kann man sich die Zahl der Aufrufe, die zum InterBase gehen, mitprotokollieren lassen. Allein von der Anzahl dieser Protokolleintr�ge k�nnen die Auswirkungen gut abgesch�tzt werden (je weniger Zeilen dort auftauchen, um so besser).

Zum Test kann man probieren, ob der Einsatz von TBatchMove die gegenw�rtige Situation verbessert. Da die Quelldaten im dBASE-Format vorliegen, kann TBatchMove automatisch ein Update/Insert in eine InterBase-Datenbank durchf�hren. Ausserdem erlaubt in diesem Fall die BDE-Konfiguration f�r den InterBase-Treiber, dass der BATCH COUNT-Wert von 200 (Anzahl der innerhalb einer Transaktion einzuf�genden Datens�tze) variiert werden kann. Aber auch hier w�rde ich mich im SQLMonitor davon �berzeugen, ob tats�chlich mehrere Datens�tze in eine Transaktion verpackt werden

**Heinz Blubber** · 07.04.2000, 09:18

Hallo Herr Kosch,

vielen Dank f�r Ihre umfassende Antwort.

Am Wochende werde ich die Applikation umschreiben. Ich werde �ber den Erfolg berichten.

Die �nderung des Netzprotokolls hat keinen Effekt gehabt

**Heinz Blubber** · 10.04.2000, 10:27

Hallo,

folgende Umstellungen habe ich vorgenommen:

- laden der seq. Dateien in ein nichtindiziertes dBase File 
- aus dem dBase-File nach Interbase wird nun via BatchMove geladen

Effekt: 70.000 Datens�tze in ca. 15 Minuten verarbeitet

Vielen Dank f�r Eure Hilfe!!

Announcement

Performenc Interbase

Performenc Interbase

Comment

Comment

Comment

Comment

Comment

Comment

Comment