TurboMed langsam wegen Netzwerk-Latenz?

[DocET]

Im vergangenen Jahr ist das Arbeiten mit TurboMed immer langsamer geworden. Nunmehr vergehen bis ca. 2 Sekunden vom Drücken der F3-Taste bis zum Öffnen der Patientenakte.

Server und PCs sind mit Gbit-Netzwerk (statische IPs) verbunden, Windows 10 auf i5-1135G7 bzw. i7-1360p, alle mit schnellen SSDs und 8...16 Gbit Speicher. Bekannte „Beschleunigungsmaßnahmen“ wie das Öffnen von Patientenakte und Karteikarte im selben Fenster und Laden der PraxisDB in den RAM des Servers sind ausgeschöpft. Die TI-Komponenten hängen in einem anderen Subnetz und sind über einen Router an das Praxis-LAN angebunden.

Die Ping-Zeit im Praxis-LAN beträgt 1…2 ms, weshalb nach meiner Vorstellung hauptsächlich noch zwei Mechanismen zur Netzwerk-Latenz (Tastendruck bis Eintreffen der Daten am Client) führen könnten:

• DNS -> im LAN eigentlich wegen statischer IPs nicht nötig
• WINs -> zwecks Zuordnung statischer IPs und PC-Namen (Server-Name in TurboMed benutzt)

Mein Mini-Test-Netzwerk bestehend ausschließlich aus je einem Clone des Servers und des Arzt-PCs, gekoppelt über einen Gbit-Switch, worauf TurboMed ähnlich langsam wie in der Praxis läuft (mit Start-Fehlermeldung „Konnektor nicht gefunden“). Schneller wird’s, wenn man beiden PCs sowohl die Eintragung vom Gateway und DNS-Server entfernt und Kommunikationsversuche über das LAN hinaus bereits dadurch unterbunden werden.

Kennen Sie dieses Verhalten? Was alles in TurboMed muss ich abstellen, damit es selbst keine DNS-Anfragen stellt und Verzögerungen wegen fehlender Antworten unterbunden werden (Clickdoc bereits deaktiviert).

Danke für jegliche Ideen im Voraus, viele Grüße von DocET

[lcer]

Hallo,

bei uns ist das auch so. Im Unterschied zu Deinem Netzwerk ist aber WINS ist bei uns netzwerkweit deaktiviert. Alles läuft über DNS. Auch in den Turbomed-Grundeinstellungen verwenden wir FQDN DNS-Namen. Bei uns liegen Server und Clients im selben Netzwerk, so dass der Router eigentlich irrelevant ist. (Allerdings weiss ich nicht, was mittlerweile so alles online passiert...)

Ich würde (bei uns) die Netzwerkkomponenten nicht Problem ansehen. Im Netzwerktrace (Wireshark) sehe ich keine Verbindungsfehler o.ä. Ich denke, dass die Serverkomponenten (z.B. Fastobjects-Server) das Problem sind. Und bei der TI/KIM-Geschichte liegen auch viele Daten nur auf dem Server und nicht auf dem Client. (Das F:\TurboMed\Daten\Var -Verzeichnis auf dem Server).

Grüße

lcer

[c-it]

• DNS -> im LAN eigentlich wegen statischer IPs nicht nötig
• WINs -> zwecks Zuordnung statischer IPs und PC-Namen (Server-Name in TurboMed benutzt)

... der 1. Punkt ist so nicht korrekt. DNS löst Namen zu Adressen auf, ob dynamisch oder statisch ist egal.
Da moderne OS alles über DNS abfragen, ist meiner Erfahrung nach genau der umgekehrte Weg sinnvoll.
WINS abschalten (wer ist denn eigentlich der WINS-server ?) und den Router als DNS-Server nutzen. Jeder
nicht-exotische Router betreibt wenigsten einen DNS-Cache-Server (z.B. Fritz!box o.ä., natürlich auch die
KocoBox).

Netzwerk-Hardware kann man testen: TMed-Update von Server auf Client schieben und wieder zurückkopieren.
Im 1 GBit-LAN sollten 100MB/s (MegaByte/s) möglich sein. Wenn das so ist, kann die Hardware aus der
Problemlösung rausgenommen werden. Die Variante von @Icer mit wireshark ist natürlich aussagekräftiger.

Ist denn ein Standard-DNS-Kontext angegeben? Wenn ja, würde ich den löschen. Dann setzt z.b. die
Fritz!box einfach ihren Kontext dazu: server => server.fritz.box usw.

Schönen Tag
c-it

[FortiSecond]

... der 1. Punkt ist so nicht korrekt. DNS löst Namen zu Adressen auf, ob dynamisch oder statisch ist egal.
Da moderne OS alles über DNS abfragen, ist meiner Erfahrung nach genau der umgekehrte Weg sinnvoll.
WINS abschalten (wer ist denn eigentlich der WINS-server ?) und den Router als DNS-Server nutzen. Jeder
nicht-exotische Router betreibt wenigsten einen DNS-Cache-Server (z.B. Fritz!box o.ä., natürlich auch die
KocoBox).

Da gehe ich mit.

Off-topic

Nur vorsorglich für andere Konstellationen, falls das hier in einer Suche auftaucht:

Im Netzwerk ohne Domäne ist das korrekt. Nur EIN Gerät, meist ja Router oder Firewall, übernimmt die Aufgabe DHCP+DNS, falls intern DHCP genutzt wird. Sonst halt nur DNS.

Im Netzwerk mit Windows-Domäne hingegen ist der Server der (erste und möglichst einzige) DNS-Server im LAN für alle Clients.
Er kann auch eine bedingte Weiterleitung der Anfragen für die TI-Domain .telematik bereitstellen. In den Clients also als erster DNS eingetragen.
DHCP? Ein ordentlicher DHCP (Router, Firewall, Windows-Server) kann ja auch noch mehr schöne Dinge erledigen, z.B. Option 121 (Routen verteilen -> TI über Konnektor und sowas). Daher die Reihenfolge der Präferenz: Firewall (24/7 + Funktionalität), Windows-Server (Funktionalität), Fritz!Box (läuft halt, meistens auch recht dauerhaft, kann aber nicht viel).

[FortiSecond]

Im vergangenen Jahr ist das Arbeiten mit TurboMed immer langsamer geworden. Nunmehr vergehen bis ca. 2 Sekunden vom Drücken der F3-Taste bis zum Öffnen der Patientenakte.

Server und PCs sind mit Gbit-Netzwerk (statische IPs) verbunden, Windows 10 auf i5-1135G7 bzw. i7-1360p, alle mit schnellen SSDs und 8...16 Gbit Speicher. Bekannte „Beschleunigungsmaßnahmen“ [...]

• An Server und einem Client zu Testzwecken die Flussteuerung deaktivieren (Netzwerkadapter-Einstellungen) und schauen, ob es sich bessert. Speziell wenn irgendwo was von Broadcom NetXTreme mit 1 oder 10 GBit im Spiel sein sollte, ist das ein Pflicht-Check. Standalone oder Onboard ist dabei egal, aber Dell-PC und -Server häufiger betroffen. Es gibt Inkompatibilitäten mit manchen Switchen. Dabei entsteht Paketverlust, der aber durch zeitraubende Retransmissions kompensiert wird. Dadurch wird es nur langsam, während auf OS-Ebene keine Paketverluste messbar sind.
  (Lediglich als Hinweis, dass es da diverse Auffälligkeiten gibt: https://docs.netgate.com/pfsense/en/lat ... ce-4-cards)
• Ggf. auch mit Wireshark auf einen Netzwerkadapter schauen: Retransmissions sind hier oft ein Problem
• Irgendwo ein uralter Switch (auch Gigabit möglich) aktiv? Oder ein Amazon-China-PoE-Switch (Tenda, Low-Name)? Die können mit manchen Sachen nicht richtig umgehen und richten Chaos an.
• VoIP-Telefone mit integriertem Switch, insbesondere Grandstream: Buggy mit Auswirkungen ins gesamte Netz. Neustart Telefon = paar Tage bis Wochen alles fein.
• Zwei DHCP-Server aktiv? Doppelte Stationsnamen (NetBEUI-Chaos)?
• Patchkabel am Server tauschen. Cat5e ist nicht immer ausreichend, gerade wenn die Kabel altern

Das hier hat nix mit Netzwerk zu tun, kann ausgeschlossen werden, wenn am Server alles richtig fix abläuft:

• Server mit 2 CPU-Sockeln ohne Bindung des FOS an eine der beiden CPU?
• Virtualisierung und nicht genug RAM für den Hypervisor übrig?
• Virtualisierung und QoS für die SSD nicht gesetzt?

Puh, die Liste ist lang.

Ach ja, hatten wir ja auch gerade vor ein paar Wochen: MS Defender -> Ausnahme auf den FOS und ggf. auch ExtPrg setzen wegen veränderter Cloud-Anbindungen. Generell Cloud-Funktionen deaktivieren (Datenschutz).
Und: Automatischer ePA-Check...
Und: Einfach mal den CGM-Assist am Client abschießen und schauen, ob´s da hakt...


Nachtrag: Jumbo-Frames in den Einstellungen der Netzwerkadapter abschalten. Zu großer Overhead bei den winzigen Paketen für TM.

[lcer]

Hallo,

Nachtrag: Jumbo-Frames in den Einstellungen der Netzwerkadapter abschalten. Zu großer Overhead bei den winzigen Paketen für TM.

nö. Das ist egal! Bei aktivierten Jumbo frames können die Pakete größer sein als normal, müssen aber nicht. Daher gibt es auch keinen Overhead. Kleine Pakete bleiben kein. Man muss aber sicherstellen, dass Netzwerkteilnehmer Jumboframes "können". Also sendender Computer, Switch, empfangender Computer und ggf. die Firewall. Können das niche alle, kommt es zu Fehlern und Re-transmissionen.

Grüße

lcer

[FortiSecond]

Hallo,

Nachtrag: Jumbo-Frames in den Einstellungen der Netzwerkadapter abschalten. Zu großer Overhead bei den winzigen Paketen für TM.

nö. Das ist egal! Bei aktivierten Jumbo frames können die Pakete größer sein als normal, müssen aber nicht. Daher gibt es auch keinen Overhead. Kleine Pakete bleiben kein. Man muss aber sicherstellen, dass Netzwerkteilnehmer Jumboframes "können". Also sendender Computer, Switch, empfangender Computer und ggf. die Firewall. Können das niche alle, kommt es zu Fehlern und Re-transmissionen.

Grüße

lcer

Jupp, hab ich unsinnig formuliert. Aussage sollte eher heißen: "TM profitiert nicht von Jumbo Frames, also gar nicht erst das Risiko eingehen".

Sind sie aktiviert, kommt es zu Verhandlungen und somit Overhead. Versucht´s einer mit 11kB-Paketen, aber der andere mag nur 9kB oder ist die MTU ohnehin unten, wird es albern. Blöd wird es bei Echtzeitanwendungen wie VoIP. Und da bei TM schon ein paar Millisekunden zum Flötenbruch gereichen (Broken Pipe), würde ich auch hier auf JF verzichten wollen.
Ob man für die paar Prozent bei größeren Übertragungen das Risiko eingehen will?
Aber wenn regelmäßig viel umhergeschoben wird, kann man das durchaus angehen. Dann aber konsequent.

[Johnny]

FortiSecond:
Und da bei TM schon ein paar Millisekunden zum Flötenbruch gereichen (Broken Pipe)

Entspricht auch meiner Beobachtung.
Aber wie kann man dies vermeiden bzw die Zeit verlängern?
(Unter Fötenbruch verstehen ich: TM -Kurzzeit-Verbindung Server/client bricht zusammen und der Client hängt und stürzt dann evtl. ab?!)

Grüsse aus Kiel
Johnny

[FortiSecond]

FortiSecond:
Und da bei TM schon ein paar Millisekunden zum Flötenbruch gereichen (Broken Pipe)

Entspricht auch meiner Beobachtung.
Aber wie kann man dies vermeiden bzw die Zeit verlängern?
(Unter Fötenbruch verstehen ich: TM -Kurzzeit-Verbindung Server/client bricht zusammen und der Client hängt und stürzt dann evtl. ab?!)

Mir ist bisher kein Weg bekannt, das clientseitige Timeout irgendwie zu beeinflussen.

Der FOS selbst hat kein Problem mit Latenzen. UDP wird nicht genutzt (dann wäre das aber fehlertoleranter implementiert).

Ob es nun Timeouts sind, oder ob bereits ein verlorenes Paket ausreicht: Nicht weiter untersucht.


Bei einer unterbrochenen oder gar erkennbar korrumpierten Transaktion auf dem Client die Notbremse zu ziehen, ist sinnvoll. So verhindert man das Risiko, mit fehlerhaften oder gar bösartigen Daten zu arbeiten und diese unter Umständen gar in die DB zu schreiben.
Serverseitig kann eine hängende Transaktion dann halt verworfen werden, ohne die DB zu beschädigen. Das ist die Aufgabe des Datenbankservers.

Clientseitig könnte man einen (anderen) Umgang mit solchen Fehlern einbauen, also längere Timeouts, Transaktionswiederholung bei Problemen und so weiter. Hat dann aber neben Performancefragen den Preis, dass die häufigste Ursache in Form einer Nichterreichbarkeit des Servers (Neustart, Kabel usw.) dann zu Sanduhr und "...reagiert nicht" führt, bevor man dann ja trotzdem abstürzt. Dann lieber die einfachere Variante mit "Crash to Desktop" beibehalten, bei der die Risiken geringer sind. Nicht zuletzt SOLLTEN solche Abbrüche und Fehlübertragungen ja vermeidbar sein, solange der Server läuft und das Netzwerk OK ist.

Am Ende bleibt also nur, für ein stabiles und ausreichend dimensioniertes Netz und einen zuverlässigen Server zu sorgen.
Gute Kabel, vernünftige Switches, ordentliche Netzwerkadapter(-einstellungen), leistungsfähige und intakte Datenträger, genug RAM, ordentliches Lastmanagement auf dem Server (z.B. keine "Windows-Serversicherung" in der Sprechzeit), echtes Server-OS, sorgfältiges Adressmanagement, Broadcast-Geraffel wie Internet-TV raushalten und so weiter. Ordentlich halt.
Weiterhin etwas Hygiene: Nicht benötigte NW-Dosen vom Switch trennen, um Konflikte oder el. Fehler zu vermeiden; Switch-Verkettung vermeiden, Pass-Through durch VoIP-Telefone vermeiden.
Und dann ab und zu mal an einem PC mit direkter Verbindung zum zentralen Switch Wireshark starten und auf rote Zeilen achten (vereinfacht gesagt).

[Australopiticus]

Auch wenn Ihr Beitrag schon etwas älter ist, würde ich mich freuen, wenn sich das Problem gelöst hat. Ich wäre dann sehr an der Lösung interessiert, da ich genau das gleiche Problem mit 2 bis 3 Sek. Wartezeit in der F3 habe. Seltsamerweise nur an einem Rechner, wo ich nach Rechnertausch auf aktuelle Hardware und 10 GB Netzwerkkarte TM zunächst als Einzelplatz und dann nach Anleitung mit den Pfadumleitungen etc. als Client installiert habe. Alles läuft superschnell, auch die Datenspiegelung und Sicherung, aber der Zugriff auf die F3 und von dort aus z.B. Aufruf eines abgespeicherten Dokumentes ist unterirdisch. Die aufgeschaltete TM Hotline konnte an den Einstellungen erstmal auch keine Fehler finden.
Deswegen: wenn Sie damals mit einer vermuteten kleinen Einstellungsänderung weitergekommen sind, wäre ich Ihnen über einen Hinweis sehr dankbar

Matthias G.

[michael]

Lesen sie doch mal hier den Beitrag: viewtopic.php?t=10033
Vllt hilft das

VG michael