FB-Server-Zugriff über DSL langsam

[hoika]

Hallo #,

ich schreibe gerade an einer Replikations-Software.
Auf dem Laptop läuft mein Programm,
der Laptop geht über DSL ins Internet auf einen FB-Server,
der ebenfalls über DSL im Netz hängt.

Problem:
Der Zugriff ist sehr zäh (um es mal freundlich auszudrücken).

pro replizierten Datensatz wird voreinfacht folgendes gemacht
remote : FB-Server
local : Laptop


remote : select * from table where id=xx
local : insert/update/delete into table

Ich kann die einzelnen Datensätze förmlich durch das Kabel kriechen sehen
edit: 45 sec für 70 Datensätze.


Dazu noch ein Frage:
beim Insert prüfe ich vorher mit
select count(*) from table where id=:xxx , ob der Datensatz nicht schon drin ist.
Ein

Select 1 from rdb$database where Exists(select id from Table where id=:xxx) ist noch langsamer (sollte das nicht schneller sein ?)


Was für Möglichkeiten habe ich, das schneller zu machen ?

Danke

Heiko
PS: Die Datenbank-Schnittstelle auszutauschen, bringt nix.

[mkinzler]

Aber vielleicht ein Update auf FB2:
-Optimierter Netzwerkzugriff
-Und 'Update or Insert into ...'!
Das Tunneln/Komprimieren der Verbindung (Zedebee/stunnel) könnte auch eine Verbesserung bringen

[Bernhard Geyer]

Welche Ping-Zeiten zum Server-Rechner hast du?
Kannst du Fast-Path beantragen?
Wie träge ist eine Rechnerfernsteuerung per Remote Desktop?

[hoika]

Hallo,

- optimierter Netzzugriff gibt es doch ab 1.5 ?
- FastPat5h -> soll später beim Kunden laufen
k.A., was der dann aht
- Ping zwischen 1 ms und <10 ms
- Insert Or Update bringt nix,
weil ich ja genau weiss, was ich machen muss
(das select count(*) ist wichtig wegen Konflikt-Erkennung)
- RDP kann ich zur Zeit nicht prüfen
Ich teste gerade lokal (Server + Client auf gleichen Rechner + gleiche DB),
verbinde mich aber mit dem DynDNS-Namen

Ich werde erst mal ausprobieren, was ein preparen der remote-Query (select * from) bringt,
ist aber nicht so einfach, weil ich theoretisch für jede Tabelle eine
eigene prepared Query bräuchte.



Heiko

[mjustin]

Zitat von hoika:

verbinde mich aber mit dem DynDNS-Namen

Ich bin kein TCP/IP Experte, aber könnte es etwas bringen, vor dem beim ersten Verbindungsaufbau zuerst die numerische IP Adresse, die über DynDNS geliefert wird, zu ermitteln und dann für die folgenden Connects zu benutzen?
Vielleicht ist die Auflösung des Namens auf die IP Adresse zeitaufwendig.

[hoika]

Hallo,

danke, aber ich mache nur ein Connect.
Ich glaube, da war auch mal was mit

SQL.Add()
SQL.Add()
SQL.Add()

ersetzen durch ein (komplettes) SQL.

Mal sehen.


Heiko

[mjustin]

Zitat von hoika:

Was für Möglichkeiten habe ich, das schneller zu machen ?

Ohne zu prüfen ein Insert versuchen: die Datenbank wird sich wehren, falls der Satz schon existiert, in allen anderen Fällen spart man ein Select.

Größere Datenpakete (jeweils z.B. immer zehn Sätze) verarbeiten könnte auch helfen, und eine Transaktion darum legen - die beschleunigt zusätzlich (da der Verwaltungsoverhead eher abnimmt).

[Hansa]

Wichtig ist schon mal das hier :

execute block Aber erst ab FB 2.0 vorhanden. Das reduziert den Traffic um Faktor 5-10 oder mehr. Am besten diesen Block mit IBExpert anlegen. Als Zugriffskomponenten zur Unterstützung ist mir nur FIBplus bekannt. Angeblich gibt es noch was über UIB.

[mkinzler]

Da Heiko (noch) mit der BDE arbeitet fällt das leider aus.
BTW. IBDAC unterstützt das natürlich auch.

[hoika]

Hallo,

das mit dem Execute Block sieht ja gar nicht so schlecht aus.
FIBPlus liegt hier rum ... blöde Altlasten ;(

Mal schauen.


Heiko