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.