AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Datenbanken WANTED: DB für schlechte Netzwerke

WANTED: DB für schlechte Netzwerke

Ein Thema von QuickAndDirty · begonnen am 17. Mär 2012 · letzter Beitrag vom 24. Mär 2012
Antwort Antwort
Seite 1 von 4  1 23     Letzte » 
QuickAndDirty

Registriert seit: 13. Jan 2004
Ort: Hamm(Westf)
1.882 Beiträge
 
Delphi 12 Athens
 
#1

WANTED: DB für schlechte Netzwerke

  Alt 17. Mär 2012, 11:28
Datenbank: ? • Version: ? • Zugriff über: Anydac
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?
Andreas
Monads? Wtf are Monads?

Geändert von QuickAndDirty (17. Mär 2012 um 11:59 Uhr)
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#2

AW: WANTED: DB für schlechte Netzwerke

  Alt 19. Mär 2012, 09:23
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.
Gruß, Jo
  Mit Zitat antworten Zitat
QuickAndDirty

Registriert seit: 13. Jan 2004
Ort: Hamm(Westf)
1.882 Beiträge
 
Delphi 12 Athens
 
#3

AW: WANTED: DB für schlechte Netzwerke

  Alt 22. Mär 2012, 11:07
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.

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.

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.

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.

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...

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....)

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?

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.

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.
Andreas
Monads? Wtf are Monads?
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.851 Beiträge
 
Delphi 11 Alexandria
 
#4

AW: WANTED: DB für schlechte Netzwerke

  Alt 22. Mär 2012, 11:19
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
Markus Kinzler
  Mit Zitat antworten Zitat
tsteinmaurer

Registriert seit: 8. Sep 2008
Ort: Linz, Österreich
530 Beiträge
 
#5

AW: WANTED: DB für schlechte Netzwerke

  Alt 22. Mär 2012, 11:28
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.)
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#6

AW: WANTED: DB für schlechte Netzwerke

  Alt 22. Mär 2012, 12:43

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.

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.

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, .. ?
Gruß, Jo
  Mit Zitat antworten Zitat
QuickAndDirty

Registriert seit: 13. Jan 2004
Ort: Hamm(Westf)
1.882 Beiträge
 
Delphi 12 Athens
 
#7

AW: WANTED: DB für schlechte Netzwerke

  Alt 22. Mär 2012, 13:11
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.

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.


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.
Andreas
Monads? Wtf are Monads?
  Mit Zitat antworten Zitat
tsteinmaurer

Registriert seit: 8. Sep 2008
Ort: Linz, Österreich
530 Beiträge
 
#8

AW: WANTED: DB für schlechte Netzwerke

  Alt 22. Mär 2012, 13:16
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.
  Mit Zitat antworten Zitat
QuickAndDirty

Registriert seit: 13. Jan 2004
Ort: Hamm(Westf)
1.882 Beiträge
 
Delphi 12 Athens
 
#9

AW: WANTED: DB für schlechte Netzwerke

  Alt 22. Mär 2012, 13:19
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?
Andreas
Monads? Wtf are Monads?
  Mit Zitat antworten Zitat
QuickAndDirty

Registriert seit: 13. Jan 2004
Ort: Hamm(Westf)
1.882 Beiträge
 
Delphi 12 Athens
 
#10

AW: WANTED: DB für schlechte Netzwerke

  Alt 22. Mär 2012, 13:26
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?
Andreas
Monads? Wtf are Monads?
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:22 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz