WANTED: DB für schlechte Netzwerke

[QuickAndDirty]

Welche Datenbank muss ich nehmen um FatClients in einem NICHT Administrierten Netzwerk zu betreiben...
(Der Netzwerk Admin ist verwand mit dem Besitzer und unfehlbar...)

Gehen wir einfach davon aus das vorliegende Netzwerk ist lahm. Und der Flaschenhals nicht direkt auffindbar Virenscanner, Firewalls, Switche, Netzwerkkarten....

Wenige große Datenpackete sind schnell übertragen aber viele kleine Datenpakete dauern....

das Programm setzte ausschließlich "Select, insert , update, delete" statements ab. In der Regel Prepared und Parametrisiert.


Ich habe schon festgestellt das MSSQL unter genannten bedingungen um längen besser funzt als Firebird

Wer hat solche Erfahrungswerte für andere Paarungen beizusteuern?

[jobo]

Sorry, das klingt etwas drollig. Ich würde versuchen, das Netz rund zu bekommen, aber Du musst ja mit den Gegenenheiten "arbeiten".

Ich kann eigentlich keine spezifischen Rankings liefern, nur ein paar allgemeine Gedanken. Fat Clients sind ja offenbar sehr geschwätzig (verglichen mit WEB basierten Systemen).
In Deinem Problembereich (Symptome) sehe ich die Netzwerkschwächen dann offenbar im Bereich Routing, Adressierung, Namensauflösung, nicht in der Bandbreite. Sprich, der DB Client ist vorwiegend damit beschäftigt, auf Antworten von DNS und Co zu warten. Große Pakete gibt es glaub ich weniger in dem Bereich.
Bei MS (in einem MS Netzwerk) gibt es ja gefühlt 50 weitere Protokolle neben DNS und DHCP), dass MS Produkte da verhältnismäßig gut mit klarkommen, ist nicht verwunderlich.
Meine Strategie wäre:
Das eigentliche Netzwerkproblem rausfinden (schlechter DNS, lokale DNS Einstellungen nach außen und vlt sogar falsche DNS Angaben, alte Protokolle, z.B. NetBUI oder wie das hies, usw.) Dann ein entsprechendes Arangement bilden.
GGf. Namensauflösung vermeiden (also Clientconfig IP basiert) oder sogar Fat Client "vermeiden". Ich weiß janicht, wie frei Du ansonsten in der "Wahl der Waffen" bist, aber mit dem Fat Client etwas näher an eine Webarchitektur zu rücken, wäre vielleicht einen Test wert. Dabei denke ich an sowas wie mORMot. Hab's noch nicht genutzt, aber wird hier gelegentlich genannt.

[QuickAndDirty]

Zitat von jobo:

Sorry, das klingt etwas drollig. Ich würde versuchen, das Netz rund zu bekommen,

Ich auch...aber ich bin kein Admin...und so forensische Analysen was Netzwerke betrifft sind sehr sehr aufwendig...und man muss ne Menge Ahnung haben. Wir haben hier wirklich nur Entwickler und Verkäufer in der Firma.

Zitat von jobo:

aber Du musst ja mit den Gegenenheiten "arbeiten".

Das kommt daher da ja alle anderen Sachen schnell durchs Netzwerk gehen...z.B. Große Archive, CAD Dateien, Worddokumente...
Nur unsere Anwendung ist langsam...also ist das aus Adminsicht ganz klar unser Problem, auch wenn wir wissen das es etliche Firmen gibt bei denen es gefühlt 15 mal schneller ist.

Zitat von jobo:

Ich kann eigentlich keine spezifischen Rankings liefern, nur ein paar allgemeine Gedanken. Fat Clients sind ja offenbar sehr geschwätzig (verglichen mit WEB basierten Systemen).

Ja, insbesondere mit FB als Basis.

Zitat von jobo:

In Deinem Problembereich (Symptome) sehe ich die Netzwerkschwächen dann offenbar im Bereich Routing, Adressierung, Namensauflösung, nicht in der Bandbreite. Sprich, der DB Client ist vorwiegend damit beschäftigt, auf Antworten von DNS und Co zu warten. Große Pakete gibt es glaub ich weniger in dem Bereich.

Der Admin will sich in dieser Richtung nicht bewegen. Auf keinen Fall kann an dingen geschraucbt werden die in seinem Verantwortungsbereich liegen, schließlich ist er eine Koryphäe der netzwerktechnik.

Zitat von jobo:

Bei MS (in einem MS Netzwerk) gibt es ja gefühlt 50 weitere Protokolle neben DNS und DHCP), dass MS Produkte da verhältnismäßig gut mit klarkommen, ist nicht verwunderlich.

Also ich war sehr überrascht das MSSQL wirklich um einiges schneller ist als FB...

Zitat von jobo:

Meine Strategie wäre:
Das eigentliche Netzwerkproblem rausfinden (schlechter DNS, lokale DNS Einstellungen nach außen und vlt sogar falsche DNS Angaben, alte Protokolle, z.B. NetBUI oder wie das hies, usw.) Dann ein entsprechendes Arangement bilden.

Ok, der teil der Strategie, ist nicht möglich (wegen Reibung mit dem Admin). (Für den ist ja auch total normal das von 4 pings 3 verloren gehen....)

Zitat von jobo:

GGf. Namensauflösung vermeiden (also Clientconfig IP basiert)

Hey das ist gut. Da habe ich noch garnicht drann gedacht! Derzeit ist FB über den Computername konfiguriert. Aber merkt sich so ein PC nicht die Auflösung eines Computernamens im Lokalen Netz?

Zitat von jobo:

oder sogar Fat Client "vermeiden".

Es handelt sich um einen 1,8 Millionen Code Zeilen FatClient... das ist so in 25 jahren Programmentwicklung aufgelaufen. Wir haben auch ein Webprodukt das wirklich gut skaliert, aber hier ist leider der FatClient gefragt.

Zitat von jobo:

Ich weiß janicht, wie frei Du ansonsten in der "Wahl der Waffen" bist, aber mit dem Fat Client etwas näher an eine Webarchitektur zu rücken, wäre vielleicht einen Test wert. Dabei denke ich an sowas wie mORMot. Hab's noch nicht genutzt, aber wird hier gelegentlich genannt.

Das intelligenteste wäre für besagtes Netzwerk über Terminalserver zu arbeiten oder das Netzwerk flott zu machen....aber intelligenz ist nunmal hier nicht angebracht, deswegen ich suche eine DB die auch mit HiPingBastard Netzwerken klar kommt.
Irgendwo muss es doch Rankings zu Geschwätzigkeit von geben.

[mkinzler]

Man könnte den Verkehr bündeln/komprimieren

http://www.winton.org.uk/zebedee/ oder http://www.stunnel.org/

Damit bekommet man sogar (FireBird-)Verkehr über das Internet gehandelt.

http://firebird.sourceforge.net/down...ebedee_eng.pdf

[tsteinmaurer]

Das Firebird-Remote-Protokoll ist bekannt "geschwätzig". Siehe auch den Lesestoff hier:

http://dyemanov.blogspot.com/2012/01...t-network.html
http://dyemanov.blogspot.com/2012/03...d-buffers.html
http://dyemanov.blogspot.com/2012/03...-batching.html

Wenn man sich aber in einem LAN befindet, dann sollte das nicht so viel ausmachen. Vorausgesetzt natürlich, dass netzwerktechnisch sowohl hardware-, als auch softwareseitig (DNS-Auflösung etc.) die Sache einigermaßen im grünen Bereich ist.

Interessant ist auch, was denn der Fat-Client so treibt. Ich hab client-seitig im Umfeld von Firebird schon viel gesehen und performancetechnisch wundert mich da manchmal gar nichts mehr. Ev. liegt ja Optimierungspotential im Fat-Client und der zugrundeliegenden Firebird Datenbank (Konfiguration, Indexes etc.)

[jobo]

Zitat von QuickAndDirty:

Zitat von jobo:

In Deinem Problembereich (Symptome) sehe ich die Netzwerkschwächen dann offenbar im Bereich Routing, Adressierung, Namensauflösung, nicht in der Bandbreite. Sprich, der DB Client ist vorwiegend damit beschäftigt, auf Antworten von DNS und Co zu warten. Große Pakete gibt es glaub ich weniger in dem Bereich.

Der Admin will sich in dieser Richtung nicht bewegen. Auf keinen Fall kann an dingen geschraucbt werden die in seinem Verantwortungsbereich liegen, schließlich ist er eine Koryphäe der netzwerktechnik.

Ich meinte auch, dass Du Dich bewegen musst. Du kannst selbst ohne Netzwerkkenntnisse mit ein paar einfachen Tests das Problem eingrenzen.
Z.B. einen Client Zugriff auf Basis der IP adresse statt DNS Name aufsetzen und Performance Tests machen.
Außerdem kann man einfach mittels Taskmanager / Netzwerktraffic sehen(!), was die Anwendung selbst für Last produziert bzw. welche Grundlast ohne Eure Anwendung da ist.

Jenach Technology oder verwendeten Kompos (alà "ultimativeTreeviewKomponente", die die halbe DB in den Tree saugt) hat man schnell mal eine riesige Tabelle im Hintergrund geöffnet und erst später den gewollten Filter appliziert. (Frage von Event Reihenfolge, usw.) Soetwas fällt häufig nicht im Entwicklersystem auf, da dort die echten Datenmengen fehlen. Also vor Ort testen und Netzwerkmoni beobachten.

Zitat von QuickAndDirty:

Zitat von jobo:

Meine Strategie wäre:
Das eigentliche Netzwerkproblem rausfinden (schlechter DNS, lokale DNS Einstellungen nach außen und vlt sogar falsche DNS Angaben, alte Protokolle, z.B. NetBUI oder wie das hies, usw.) Dann ein entsprechendes Arangement bilden.

Ok, der teil der Strategie, ist nicht möglich (wegen Reibung mit dem Admin). (Für den ist ja auch total normal das von 4 pings 3 verloren gehen....)

S.o. unabhängig vom Admin kannst Du sicher selbst ein paar Sachen abchecken.

Zitat von QuickAndDirty:

Zitat von jobo:

oder sogar Fat Client "vermeiden".

Es handelt sich um einen 1,8 Millionen Code Zeilen FatClient... das ist so in 25 jahren Programmentwicklung aufgelaufen. Wir haben auch ein Webprodukt das wirklich gut skaliert, aber hier ist leider der FatClient gefragt.

ok, wieviel Clients sind da in Betrieb.
>Ein< geschwätziger Fat Client plus ein paar Missgriffe in der anwendung selbst sind ja nicht schlimm, aber 100, .. ?

[QuickAndDirty]

Zitat von jobo:

Zitat von QuickAndDirty:

Zitat von jobo:

In Deinem Problembereich (Symptome) sehe ich die Netzwerkschwächen dann offenbar im Bereich Routing, Adressierung, Namensauflösung, nicht in der Bandbreite. Sprich, der DB Client ist vorwiegend damit beschäftigt, auf Antworten von DNS und Co zu warten. Große Pakete gibt es glaub ich weniger in dem Bereich.

Der Admin will sich in dieser Richtung nicht bewegen. Auf keinen Fall kann an dingen geschraucbt werden die in seinem Verantwortungsbereich liegen, schließlich ist er eine Koryphäe der netzwerktechnik.

Ich meinte auch, dass Du Dich bewegen musst. Du kannst selbst ohne Netzwerkkenntnisse mit ein paar einfachen Tests das Problem eingrenzen.
Z.B. einen Client Zugriff auf Basis der IP adresse statt DNS Name aufsetzen und Performance Tests machen.
Außerdem kann man einfach mittels Taskmanager / Netzwerktraffic sehen(!), was die Anwendung selbst für Last produziert bzw. welche Grundlast ohne Eure Anwendung da ist.

Das mit dem umgehen des DNS ist eine idee die ich ganz vergessen hatte das kann man versuchen.
Traffic und prozessorlast habe ich gemessen. Prozessorlast immer unter 2% und traffic wenige KB/s Bandbreite in den spitzen. Ich wünschte ja es wäre mehr! Er soll sich die Bandbreite und Rechenzeit nehmen...er tut es nur nicht. Habe die Ursache schon soweit eruiert das die Latenz das Problem ist. Leider ist FB auch besonders anfällig für schlechte Latenz weil viel über ping pongs läuft.

Zitat von jobo:

Jenach Technology oder verwendeten Kompos (alà "ultimativeTreeviewKomponente", die die halbe DB in den Tree saugt) hat man schnell mal eine riesige Tabelle im Hintergrund geöffnet und erst später den gewollten Filter appliziert. (Frage von Event Reihenfolge, usw.) Soetwas fällt häufig nicht im Entwicklersystem auf, da dort die echten Datenmengen fehlen. Also vor Ort testen und Netzwerkmoni beobachten.

Ja ich kenne das Dilema. Hatte ich auch mal bei einem Piloten. Hier handelt es sich allerdings um eine Software die auf vielen tausend Kunden Netzwerken absolut flüssig läuft.

Zitat von jobo:

Zitat von QuickAndDirty:

Zitat von jobo:

oder sogar Fat Client "vermeiden".

Es handelt sich um einen 1,8 Millionen Code Zeilen FatClient... das ist so in 25 jahren Programmentwicklung aufgelaufen. Wir haben auch ein Webprodukt das wirklich gut skaliert, aber hier ist leider der FatClient gefragt.

ok, wieviel Clients sind da in Betrieb.
>Ein< geschwätziger Fat Client plus ein paar Missgriffe in der anwendung selbst sind ja nicht schlimm, aber 100, .. ?

Ein Server und 2 Fatclients der Rest wird über das Web abgewickelt. Wobei der Webserver im prinzip auch als MegaFatClient zählt.

[tsteinmaurer]

Sofern die existierende Lösung auf Firebird und im speziellen auf 2.5 basiert, dann wirf mal die Trace API an, um ein Gefühl dafür zu bekommen, was client-seitig so abgesetzt wird.

[QuickAndDirty]

Zitat von mkinzler:

Man könnte den Verkehr bündeln/komprimieren

http://www.winton.org.uk/zebedee/ oder http://www.stunnel.org/

Damit bekommet man sogar (FireBird-)Verkehr über das Internet gehandelt.

http://firebird.sourceforge.net/down...ebedee_eng.pdf

Ja darauf bin ich auch schon gestoßen. Aber ich bin bereit zu wechseln...Anydac unterstützt ja eine breite auswahl an DBs .
Gibts Datenbanken die von natur aus weniger geschwätzig sind?

[QuickAndDirty]

Zitat von tsteinmaurer:

Sofern die existierende Lösung auf Firebird und im speziellen auf 2.5 basiert, dann wirf mal die Trace API an, um ein Gefühl dafür zu bekommen, was client-seitig so abgesetzt wird.

Dem ist so
Ist die 64Bit Variante (ja die soll ja auch noch langsamer sein....als die 32Bit Version)

Ich weiß das FB geschwätzig ist...
Wonach soll ich in dem Trace suchen?

Wir kennen in etwa die Probleme mit dem Protokoll...(warum z.B. ein Prepare echt viel Zeit kosten kann.....&c.)

Aber so eine DB die ein bisschen besonders wenig anfällig für latenz ist (wenige ping pongs) kennst du nicht?