WANTED: DB für schlechte Netzwerke

[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 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?

[mschaefer]

Als Vergleich würde ich neben MSSQL mal Interbase testen, da hier wohl keine Veränderungen im Code gemacht werden müßten.
Und ich neige dazu mal einen Test mit verschiedenen Datenzugriffskomponenten zu machen.

Wenn kleine Datenpakete verlorengehen und große problemlos laufen, dann geht irgendeine Komponente im Netz zwischendurch schlafen. Entweder Ihr findet den Schuldigen durch geduldige Pingtest, oder Ihr baut schlicht eine Pingkomponente in Euer Programm ein, damit der Schlaf keine Chance hat.

Und bei der kommerziellen Variante sehe ich das wie Markus.

Grüße // Martin

[tsteinmaurer]

Puh, da ist was los. Ist man mal ein paar Stunden weg ...

@QuickAndDirty: Auf deine mehrfach gestellte Frage:

Zitat:

Hast du Erfahrungen was schlechte Netzwerke und verschiedene DBs angeht?

Nein. Ich verdiene auch nichts dabei Firebird zu verteidigen, außer wenn du bei mir kommerzielle Unterstützung zur zielorientierten Problemlösung (die in einem öffentlichen Forum manchmal schwer ist) suchst.

Darum wünsch ich dir Alles Gute bei der Problem- und Lösungsfindung, die für dich und deine(n) Kunde(n) letztendlich zufriedenstellend ist. Und das meine ich nicht ironisch!

[mkinzler]

Zitat:

Darum wünsch ich dir Alles Gute bei der Problemfindung

. Und natürlich auch der Lösung

[QuickAndDirty]

Zitat von tsteinmaurer:

Puh, da ist was los. Ist man mal ein paar Stunden weg ...

@QuickAndDirty: Auf deine mehrfach gestellte Frage:

Zitat:

Hast du Erfahrungen was schlechte Netzwerke und verschiedene DBs angeht?

Nein. Ich verdiene auch nichts dabei Firebird zu verteidigen, außer wenn du bei mir kommerzielle Unterstützung zur zielorientierten Problemlösung (die in einem öffentlichen Forum manchmal schwer ist) suchst.

Darum wünsch ich dir Alles Gute bei der Problem- und Lösungsfindung, die für dich und deine(n) Kunde(n) letztendlich zufriedenstellend ist. Und das meine ich nicht ironisch!

Danke!, vermutlich werden wir uns da selbst rein knien müssen und dem Admin sein Netzwerk konfigurieren/reparieren....am Ende können wir dann unseren Techniker vermutlich nichtmal in Rechnung stellen....

Es wäre so schön wenn sich Leistungserschleichungen dieser Art umgehen lassen würden....

[BUG]

Zitat von QuickAndDirty:

Es wäre so schön wenn sich Leistungserschleichungen dieser Art umgehen lassen würden....

Theoretisch könnte man Leistungsanforderungen an das Netz mit in die Mindestanforderungen schreiben und zum Vertragsbestandteil machen.