![]() |
Datenbank: ? • Version: ? • Zugriff über: Anydac
WANTED: DB für schlechte Netzwerke
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? |
AW: WANTED: DB für schlechte Netzwerke
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. |
AW: WANTED: DB für schlechte Netzwerke
Zitat:
Zitat:
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:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Irgendwo muss es doch Rankings zu Geschwätzigkeit von geben. |
AW: WANTED: DB für schlechte Netzwerke
Man könnte den Verkehr bündeln/komprimieren
![]() ![]() Damit bekommet man sogar (FireBird-)Verkehr über das Internet gehandelt. ![]() |
AW: WANTED: DB für schlechte Netzwerke
Das Firebird-Remote-Protokoll ist bekannt "geschwätzig". Siehe auch den Lesestoff hier:
![]() ![]() ![]() 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. :-D Ev. liegt ja Optimierungspotential im Fat-Client und der zugrundeliegenden Firebird Datenbank (Konfiguration, Indexes etc.) |
AW: WANTED: DB für schlechte Netzwerke
Zitat:
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:
Zitat:
>Ein< geschwätziger Fat Client plus ein paar Missgriffe in der anwendung selbst sind ja nicht schlimm, aber 100, .. ? |
AW: WANTED: DB für schlechte Netzwerke
Zitat:
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:
Zitat:
|
AW: WANTED: DB für schlechte Netzwerke
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.
|
AW: WANTED: DB für schlechte Netzwerke
Zitat:
Gibts Datenbanken die von natur aus weniger geschwätzig sind? |
AW: WANTED: DB für schlechte Netzwerke
Zitat:
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? |
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:51 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz