interbase+delphi+netzwerk

[Thomas Zimmermann]

hallo,
ich möchte eine anwendung schreiben, die auf eine db online zugreift. die db soll sich auf einem beliebigen rechner außerhalb unseres gebäudes befinden können, zugriff über eine tcp verbindung. nun haben wir schon einiges test gemacht und prinzipell funktioniert es auch, aber der connect dauert ca. 20 sec. und selbst ein einfacher query dauert mindestens 8 sec, also zu lange.
nun haben wir uns überlegt eine middleware einzusetzen. womit programmiere ich jetzt diese middleware?
variante 1: com+ und delphi, client+serverseitig

variante 2: delphi + java ejb + corba, damit es systemunabhängig ist.

jeweils mit interbase/firebird

hat jemand eine idee für eine gute performance- lösung??

ist interbase dafür überhaupt die richtige db?

gemacht haben wir unsere ersten tests mit folgenden db
db : interbase 6 und firebird (neuste version) und mysql

alles unter delphi 6

gruß
thomas

[Gerhard Behnke]

Hallo Thomas,

sicher ist der Einsatz einer Middleware der richtige Ansatz aber unabhängig davon verstehe ich die Reaktionszeiten überhaupt nicht. Wir setzen FB 1.5 und IBObjects ein und stellen eine Verbindung über ISDN, als schnellste Medium, über Standardmodem, VPN und auch über Handy (max. 9600 b/s) her, ohne solche Geschwindigkeitsprobleme zu haben. Unsere DB läuft auf einem W2000-Server und ist cirk. 10 GByte groß (enthält etwa 2Millionen Dokumente)
Noch etwas zu Deiner Frage bezüglich der Middleware.
1.)Zuerst solltest Du dich fragen, ob die Systemunabhängigkeit wirklich benötigt wird. Wenn nicht und Ihr W2000 oder ggf. später W2003 einsetzt ist der MTS (COM) bestimmt keine schlechte Wahl zumal er ja Bestandteil der W-Servers ist. Abhängig von des geplanten Einsatztermines ist sicherlich auch eine Überlegung in Richtung .Net nicht verkehrt

Gruß
Gerhar

[Thomas Zimmermann]

hallo,
das bedeutet, dass ihr über ibo direkt connected? wir habens bisher mit den ib komponenten gemacht und eine verbindung a la server:dbname aufgebaut. kann die ursache der performance an einer firewall liegen - dachte eigentlich, das die daten durchläßt oder auch nicht aber nicht verzögert.
ist ibo denn so viel schneller als die ib komp. von borland? oder ist nur die entwicklung einfacher bzw. angenehmer.
muß man beim db-server noch irgendetwas einstellen?

ps. unsere db hat knapp 400 Tabellen und max. 25 DS pro Tabelle (also eigentlich nichts).
charset iso8859 und sqldialect 3.
gestestet haben wir mit ISDN und DSL.

was macht dir denn anders? außer mit ibo arbeiten.
gruß
thoma

[Gerhard Behnke]

Hallo Thomas,

habe gerade mal mit einer TIBDataBase-Komponente eine Verbindung über ISDN mit unserem DB-Server hergestellt (geht übrigens auch über einen Proxy). Verbindungszeit im Schnitt 0,5 Sekunden.
Kann es sein, dass Ihr z.B. mit einem Grid arbeitet, welches erst einmal alle Daten oder zumindest einen großen Teil rüberzieht ?
Ich würde deshalb nochmals prüfen, was denn so lange dauert. Die DB-Verbindung oder bis die Anwendung ggf. erst einen großen Teil der Daten rübergeschaufelt hat.
Nur als Anhaltspunkt:
Das Lesen eines Dokumentes (cirk. 8KByte)bei uns bzw. bis es auf dem Schirm erscheint, dauert einschließlich des "Select from.." über ISDN cirk. 2 Sekunden.
Noch was wichtiges:
Ab FB 1.5 RC4 oder RC5 werden VarChar Felder nicht mehr in voller Länge übertragen (wie bei IB 6.0 oder FB 1.0) sondern nur noch die Daten, die im Varchar Feld stehen. D.h., wenn Du ein Varchar Feld mit einer Größe von 1KByte in Deiner DB hast, wurden die bisher in voller Größe übertragen auch wenn vielleicht nur 100 Bytes enthalten sind. Wir haben uns damals für IBObjects entschieden, weil diese zum damaligen Zeitpunkt und wie man so hört, auch heute noch qualitativ besser und stabiler sind. Einfacher damit zu entwickeln ist es allerdings nicht. Jason Wharton hat unheimlich viel Funktionalität hineingepackt, die es einem erlaubt an sehr vielen "Schrauben" zu drehen. Dadurch ist die Lernkurve recht hoch, aber es lohnt sich. Alles weiß ich immer noch nicht und manches habe ich auch noch nicht verstanden, aber es gibt eine prima Newsgroup mit sehr schnelle Reaktionszeiten.

Gruß
Gerhard

P.S. Ich denke zwar, dass Ihr mit IBOjects im Detail schon etwas schneller sein könnt. Aber Eurer Problem liegt mit größter Sicherheit nicht an den IB-Komponente

[Thomas Steinmaurer]

Angenehmen Sonntag ;-),<br><br>
das erste was ich in so einem Fall mal machen würde ist, dass man eine SQL Monitor Komponente (IBX hat auch eine, kann jetzt aber nicht genau sagen wie die heißt) reinschaltet, damit man sieht was nun eigentlich vom Server gefetched wird. Ich bin mir ziemlich sicher, dass hier einfach bestimmte Spielregeln für eine WAN-Umgebung nicht eingehalten werden (z.B. keine unnötigen SELECT * FROM ..., kein FetchAll, keine unnötigen Prepares, kein Locate, usw...). Mit der SQL Monitor Komponente wirst Du Dich vermutlich wundern, welchen Traffic Deine Client-Anwendung produziert.<br><br>
Wenn sich nun herausstellt, dass die Anwendung einfach nicht für diese Umgebung konzipiert wurde, und ein komplettes Redesign notwendig wäre, und Du auch noch unter Zeitdruck stehst, aber schnell etwas aus dem Hut zaubern mußt, dann sieh Dir mal <b>ZeBeDee</b> an. Eine gute Doku in Verbindung mit Firebird gibt es hier http://www.ibphoenix.com/a471.htm.
<br><br>
Das wird vielleicht zu Beginn helfen, aber es wird keine Wunder bewirken, sprich die Designprobleme in Deiner Anwendung werden damit nicht beseitigt.<br><br>
Viel Glück,<br>
Thoma

[Thomas Zimmermann]

hallo,
wir haben mittlerweile 3 kleine testprogramme geschrieben. Alle bestehen aus einem memofeld, in das man eine sql anweisung eingeben kann und unten zu ausgabe eine ib-db-grid komponente.
sobald man sagt db.connect, dann dauert es erstmal 15-20s . in unseren testprogrammen haben wir nur unterschiedliche wegen der verbindungsherstellung verwendet. bde,odbc,ado... aber es ist immer zu langsam auch mit der firebird 1.5 . nur der test über eine middleware war deutlich schneller.
wir haben immer nur 1 connection hergestellt und dann eine "select * from tabelle" anweisung ausgeführt, die dann ca. 8-10 sek. gedauert hat.

gruß
thoma

[Thomas Zimmermann]

hallo Thomas,
das problem ist nicht auf meinem mist gewachsen sondern ist das Erbe meines Vorgängers. Ein Kollege hat eine firebird ma auf seinem linux system laufen lassen und dann aus der firma connected. Nach seinen Aussagen liegt es nicht an dem query oder an der Datenmenge selbst, sondern "schlicht weg" an der Übertragung selbst. man könnte meinen, dass der server noch irgendetwas anderes anstellt, bevor er die daten sendet. das mit der SQL-monitor-komp. werde ich mal ausprobieren.

gruß und vielen dank
thoma

[Henry Krick]

Hallo Gerhard,

du schreibst das du über die IBDatabase-Komponente und einer ISDN Leitung eine Verbindung herstellen kannst. Ist das eine besondere Funktion dieser Komponente oder steckt da noch mehr dahinter.
Mich interessiert dies, weil ich eben genau so eine Funktion realisieren muss und zudem Problem noch, auf der Suche nach der richtigen Datenbank bin.

Vielleicht kannst du mir noch ein Tip geben.
Wo liegen die Vorteile von Interbase?

MfG

Henr

[Florian Hector]

Henry,

die Datenbank der Wahl ist m.E. nicht Interbase sondern Firebird, also der Open Source Abkömmling von Interbase.
Wenn du über eine schmalbandige Leitung zu solch einer DB verbinden willst, gibt es die Freeware ZeeBeeDee, zu finden hier:
<PRE>
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_zebedee
</PRE>
Damit werden die Pakete verschlüsselt und komprimiert bevor sie auf die Reise gehen.

Floria

[Gerhard Behnke]

Hallo Henry,

zuerst muss ich sagen, dass wir Firebird einsetzen und nicht Interbase. In diesem Sinne stimme ich mit Florian überein. Bei FB 1.0 und IB 6.0 gab es keine Unterschiede. Ab FB 1.5 gibt es eine ganze Menge. U.a. werden VarCchar nicht mehr in der vollen Länge übertragen sondern nur noch die enthaltenen Daten. Der Optimisier wurde so verbessert, dass eine z.T. erhebliche Performancesteigerung eingetreten ist usw. usw.
Vorteile ? Tja, was soll ich Dir da schreiben bzw. gegen welche andere DB soll ich vergleichen ?
Am besten ich sage Dir mal unsere Gründe für FB.

1.)Für uns nicht der absolut entscheidende aber doch auch nicht unwichtigste Punkt, die Kosten. FB ist open source

2.)Wir benötigten eine DB, die unter WIN95 (Laptop) bis XP (Server) läuft.

3.Transaktionssicherheit

4.)Hohe Zuverlässigkeit (Wir speichern pro Tag zwischen 8 000 und 10 000 Dokumente in Echtzeit. D.h., die angeschlossenen Clients werden sofort über eine Veränderung im Dateneingang in Form einer entsprechend aktualisierten Übersicht informiert.)

5.)Ausreichende Performance (Ab FB 1.5 sehr gut)

6.)Es gibt sehr gute Komponenten für die Anbindung an die DB (Wir verwenden IBObjects)

7.)Es gibt recht guten Support (Newsgroups oder gegen Bezahlung
http://www.dibug.de/
http://www.ibphoenix.com/)
usw.

Ich hoffe, die genannten Punkte sind Dir bei der Suche nach der richtigen DB hilfreich. Aber die richtige DB wird es wohl nicht geben. Ich denke jede Auswahl wird letztendlich ein Kompromiss darstellen, wobei die Pros natürlich überwiegen sollten.

Gruß
Gerhar

[Thomas Zimmermann]

hallo henry,
interbase ist kostenlos, firebird auch ABER die ib-kompnenten funktionieren mit firebird nur solange sie auch mit interbase funktionieren würden.
am besten wirst du wohl mit ibobjects gehen.

die verbindung über eine isdn leitung geschieht dadurch, das wir über tcp/ip connecten und dann auf die datenbank mit "servername:c:\test.gdb" als datenbankname zugreifen. servername kann dabei auch die ip sein.

gruß
thoma