Guten Tag zusammen,

folgendes Problem bereitet mir momentan Kopfzerbrechen.
Auf unserem Server habe wir eine Reaktionszeit in der Software von 1 Sekunde (Schnell).
Wenn nun ein Client darauf zugreift, benötigt er für die gleiche vorgehensweise 5 Sekunden (langsam).

Folgende Dinge habe ich schon durchgeführt:
- Backup und Restore der Datenbank - kein Erfolg
- Firewall deaktiviert - kein Erfolg
- Antiviren Programm deaktiviert - kein Erfolg

Meine Frage an euch
Hat jemand noch eine Idee?
Muss bei den FibPlus Komponenten noch irgendeine "Eigenschaft" eingeschaltet bzw. ausgeschaltet werden?
Kann ich fest stellen, wo die Zeit flöten geht?
Gibt es Analysetools alla "hier ist dein Problem"?

Für zahlreiche Ideen bin ich dankbar.

Grüße
Eppos

Handelt es sich um eine komplexe Abfrage und möglicherweise nicht erzeugte Indices.

Ist der Server ein Domaincontroler?

@MrSpock
Die Abfragen sind nicht besonders komplexe aber dafür ca. 100 Stück. Indexe sind gesetzt.
Wenn die Indexe nicht gesetzt wären, würde die Abfrage auf dem Server nicht dann auch langsam laufen?

@QuickAndDirty
In diesem Fall ist es ein Domainencontroller.

Welchen Durchsatz hat die Netzleitung?
was tut sich bei Ping und traceroute?

Gruß
K-H

@p80286

Netzwerkkarten:
Client: 100 Mbit
Server: 1000 Mbit
Switch: 1000 Mbit

PING:
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit=3ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit=3ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit=5ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit=3ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.23.100: Bytes=32 Zeit<1ms TTL=128

Traceroute:
Routenverfolgung zu 192.168.100.23 über maximal 30 Abschnitte
1 <1 ms <1 ms <1 ms server.intern1.local [192.168.100.23]

Zitat von Eppos:

@QuickAndDirty
In diesem Fall ist es ein Domainencontroller.

Firebird ist auf Domaincontrollern super lahm!
Es wird dringend davon abgeraten Firebird auf einem Domaincontroller zu betreiben,
das liegt daran, weil die Domaincontrollerinstallation das windowsinterne Schreibcacheverhalten ändert.
Nach einer Deinstallation des Domaincontrollers wird der FB auch nicht schneller!
Man muss die Einstellungen in der Registry von Hand umstellen!

hier der Bugtracker
http://tracker.firebirdsql.org/browse/CORE-3890

Hallo,

der Unterscheid kommt vom Traffic.
Die App auf dem Server bekommt die Daten direkt über den Speicher,
die App im Netz muss sie sich erst "mühsam" übers Netz laden.

Hier hilft nur Reduktion der Datenmenge, also kein "Select *"
und bei komplexen Updates oder Rechnereien Stored Procedures nehmen.

Ausserdem hilft es, mit prepared Queries zu arbeiten,
wenn die Abfragen sich nur im Where unterscheiden.
Das hilft aber auch der App auf dem Server.

Ein Traffic-Monitor ist z.B. hier

http://www.delphipraxis.net/129215-t...Bv1-4d%5D.html

Heiko