Neuer Server / Performance-Problem mit TM

[mhh]

Ich muss das Thema nochmals aufwärmen:

Ich führe eine hautärtzliche Einzelpraxis mit 2-3 MFA. Nach einem Serverwechsel (der alte hatte 7 Jahre auf dem Buckel), ist das System nicht performanter geworden. Die jetzige Hardware: Windows Server 2016, 4 Kern Xeon mit 3,5 GhZ Taktung, 16 Gb RAM, nur SSD Platten im RAID, RDP Stationen (VSpace von Ncomputing).
Programme wie Word etc. laufen in normaler Geschwindigkeit. TurboMed ist langsam, lästig langsam. Folgende Zeiten habe ich beispielhaft gemessen:
1) Aufruf der graphischen Wartezimmerliste: erscheint 4s nach Aufruf
2) Patientenaufruf aus Wartezimmerliste, nach Mausklick: 4s bis Karteikarte dann it F3 geöffnet ist.
3) Öffnen der Medikamentenliste aus der Patientenakte: 7-8s (da muss ja F8 zweimal gedrückt werden bis die eigene Liste erscheint)
4) Öffnen der Langrezeptliste aus der Patientenkarteiansicht: nur 1-2s ....

Ist das normal?

Im Grundsatz läuft alles sehr zäh. Die Bedienung ist also alles andere als flüssig, obwohl direkt auf dem Server gearbeitet wird. Es nervt in einem Betrieb, in dem an einem Morgen durchaus mal 40 Patienten gesehen werden.

An welcher Stellschraube kann man TM noch Beine machen?
Ich habe die Version 20.2.2.4528.

Danke!
Martin

Dank für jeden Tipp!

[rfbdoc]

Ist auf dem TurboMed Laufwerk der Schreibache aktiviert ?
Sind TurboMed und das Serverbetriebssystem auf der selben Festplatte installiert ? Dann lässt sich nach meinem Kenntnisstand der Schreibcache nicht aktivieren.
TM läuft nur mit aktiviertem Schreibcache performant.

[hofeBY]

@mhh

Verstehe ich Sie richtig, das alle Clients kein eigenes TM istalliert haben und über RDP Client bzw.
Thinclient auf den TM-Server zugreifen ?
Ich meine gelesen zu haben, das TM-Server und RDP-Serverdienst auf einer Maschine nicht freigegeben ist.
Zu (VSpace von Ncomputing) kann ich nicht´s schreiben, kenne ich noch nicht, bin aber Intressiert.

Das Bootsystem und das TurboMed Laufwerk sollten auf verschiedenen physischen Laufwerken sein, damit
der Schreibcache auf D:\ TM zu Gute kommt.

Auf dem RDP-Server haben Sie ?:\TurboMed\Programm\TSConfig.exe ausgeführt und entsprechende Anpassung vorgenommen ?

Die Netzwerkumgebung ist Fehlerfrei, von unnützen Protokollen bereinigt und die Namensauflösung funktioniert ?

?:\TurboMed\Programm\PTserver.cfg ist auf Performance gepatched.

Was sagt das CheckupTool ? (Installationsdatenträger)

Welcher Virenscanner ist installiert ?

Ich schreibe gerade eine neue Wiki für performaten TM-Serverbetrieb (Eigene Erfahrungswerte).

Interesse ?

HofeBY

[mhh]

Ist auf dem TurboMed Laufwerk der Schreibache aktiviert ?
Sind TurboMed und das Serverbetriebssystem auf der selben Festplatte installiert ? Dann lässt sich nach meinem Kenntnisstand der Schreibcache nicht aktivieren.
TM läuft nur mit aktiviertem Schreibcache performant.

Das Betriebssystem und TurboMed sind auf separaten SSDs installiert.

Warum Schreibcache bei SSD? Windows Server deaktiviert automatisch bei der Installation den Cache bei SSDs. Ist dieser wirklich nötig, denn es erhöht sich die Gefahr der Dateninkonsistenz. Werde es aber testen und nachberichten

[mhh]

@HofeBY

Vielen Dank für die vielen Tipps.

1) Ja, ich nutze VSpace. wurde von EWerk auch mal für TM vertrieben. Ist eien Desktop Virtualisierung, strompsarend, zentral zu managen, leise, klein... siehe: https://www.ncomputing.com/products/vSp ... %20Edition und z.Bsp: https://www.schwarz-distribution.de/thi ... computing/

1) Warum Cache für SSD-Festplatten?
2) "Auf dem RDP-Server haben Sie ?:\TurboMed\Programm\TSConfig.exe ausgeführt und entsprechende Anpassung vorgenommen ?" -->Ups, das habe ich nicht gemacht. Habe TM von einem Profi installieren lassen. Vielleicht hat der das übersehen, oder, da ich noch einen einzigen fat client im Backoffice habe, wurde das explizit nicht auf RDP geändert? Sollte man das tun, was passiert dann mit dem Fatclient?
3) Netzwerkumgebung ist ok.
4) PTserver.cfg -->das habe ich eingestellt: keepAliveTimeout=6000 keepAliveInterval=10
5) Checkuptool: da TM von einem Profi installiert wurde, habe ich darauf verzichtet. Werde es nachholen.
6) Virenscanner: Panda adaptive defense 360. Diesen hatte ich schon auf dem alten Server. Kann ihn mal ausschlaten und sehen was passiert.
7) für die Mitarbeit an einem Wiki für performanten Serverbetrieb für TM fehlen mir sicher die notwendigen Kenntnisse.

Der interessanteste Punkt dürfte 2) sein. Soltle ich trotz des Fatclient umstellen?
Danke! Vielen Dank!

Der interessanteste Punkt ist

[nmndoc]

Also, auch ich halte das Thema Cache bei SSDs für stark überbewertet. Wobei man hier ggf. nochmal im Detail nachsehen muss, um welchen es sich genau handelt den man da ein/aus schaltet da ggf. an verschiedenen Stellen ein Cache potentiell vorhanden ist dh Betriebssystem/Controller/Controller-der-SSD. Nicht jeden davon kann man m.E. beeinflussen.
Auch Betriebssystem / TM getrennt - ja - kann man machen - sollte man aus anderen Gründen (zB Backup/Restore) evtl. auch - aber solange es sich nicht um eine riesige Praxis handelt *darf* das keinen nennenswerten Einfluß auf die Performance haben, da 4000-90000+ IOPs sicher nicht den Flaschenhals darstellen.

Ferner ist meine Erfahrung dass TM per RDP noch am performantesten läuft - auch ohne TSconfig.

I.d. Regel dürfte es doch so sein: TM hängt mal wieder - CPU/RAM/Netzwerk/Festplattenwarteschlange alle irgendwo bei kaum genutzt - und trotzdem läuft es eben nicht. M.E. ist nach wie vor das Hauptproblem a) das Programm selbst/Datenbankanbindung bzw. u.U. auch einfach ungünstige/schlechte Abfrage der Daten aber insbesondere die schlecht gelöste Verzahnung aus zahlreichen Einzelkomponenten wie CGM Assist, HAEVG-Modul, ifap, ifox, TI, ... usw usw usw Wir hatten schon Fälle wo ich meine wegen eines Problems mit HZV manche Formulare nicht mehr gingen, obwohl die damit nichts zu tun haben.

Dennoch nimmt man (ich) natürlich immer alle Hoffnungsschimmer dankbar auf.

[BaGo]

Wir haben eine Zwischenlösung gefunden.

Ich habe die letzten Wochen viel getestet, gemessen und ausprobiert.

Das Problem (bei uns) ist die Ifab Datenbank. Es ist das Zusammenspiel zwischen Windows, Turbomed und Ifab. Das ist so

ressourcenfressend, dass wir nun Ifab teilweise abgeschaltet haben. Nach hochfahren der Rechner beenden wird Ifab, dies

sorgt für einen flüssigen TB Ablauf im Netz. Wird es dennoch mal gebraucht, lädt TB es bei Anforderung nach, danach beenden wir den Prozess gleich wieder.

Bei uns ist das Arbeiten so erträglich geworden. Auch ist der Traffic im Netzt wesentlich weniger geworden, vielleicht hilft es dem Einen oder Anderen es mal auszuprobieren.

[mhh]

.....
Ferner ist meine Erfahrung dass TM per RDP noch am performantesten läuft - auch ohne TSconfig.

......

MIt anderen Worten: die von mir festgestellten 'Wartezeiten' sind bei TM üblich? Dann wird es Zeit für eine Umbenennung in SM: SnailMed.

[mhh]

Wir haben eine Zwischenlösung gefunden.


Das Problem (bei uns) ist die Ifab Datenbank. Es ist das Zusammenspiel zwischen Windows, Turbomed und Ifab. Das ist so

.

Ein Kollege hat relativ konsequent auf Wirkstoffverordnung umgestellt, alles unter F4. Das hat TM beschleunigt, isnbesondere wenn man IFAP abschaltet. Das wäre auch meine ultima ratio. Würde aber nur einen Teil der Probleme lösen.

[Randolf]

Hallo
der hier genannte Vermutung, daß die Probleme im Zusammenspiel vom Windows, PVS-Turbomed, IFAP und bestimmt auch noch dem Virenscanner begruendet sein könnten, beschleicht mich auch schon sehr lange. Was aber hat daran den "Löwenanteil" ? Vermute fast eher Windows oder das Antivirusprogramm ?

Komisch war, daß wir unter Windows XP-Windows 7, auch schon mit IFAP Benutzung , mit Dual Core Rechner Ausstattung, und selbst mit unpassendem "Avira" einen normalen Praxisbetrieb im Netz durchfuehren konnten. Es ist alles etwas "nebulös" .
Freue mich auch ueber jede weitere neue Anregung zum Versuch der Optimierung
Grueße Randolf

[mhh]

@Randolf

Willkommen im Club!

Ich hatte vorher Win Server 2008R2, mit jahrelag sehr guter Performance, nur die letzten ca. 3 Jahre merkte man einen Einbruch. Ich dachte das neue System würde mich wieder zurück katapultieren auf das alte Niveau. Aber es ist tendenziell sogar schlechter geworden. Ursache: unklar. Jedenfalls läuft Word und MedOrganizer unverändert, dagegen läuft TM sehr zäh. Daher glaube ich, liegt das Hauptproblem an TM, aber nicht nur.

Jedenfalls kann ich so mit TM keine flüssige Sprechstunde durchführen, insbesondere wenn es in den nächsten Jahren langsamer wird, was absehbar ist. Das ist für mich ein Wechselgrund, wenn es keine Lösung für das Performanceproblem gibt. Wir im Team, also auch meine MFAs, sind enttäuscht von der Geschwindigkeit.

Gruß
Martin

[BaGo]

Wir nutzen einen Server zZt. noch 2008 R2 und 6 Clients, alles Windows 10 prof. keine Virenscanner aktiv, wir sind nicht im Inet.

Nur ein getunnelte Verbindung zur CoCo - Box für die TI.

Turbomed als Software ist ein einziger Flickenteppich, zusammengestückelt aus diversen schlecht nachprogrammierten Modulen, deren Zusammenspiel einfach mangelhaft ist.

Das Ergebnis ist: Eine performante Nutzung ist nur möglich wenn Ifab abgeschaltet ist.

Eigentlich müsste man die Software wechseln, um wieder vernünftig arbeiten zu können. Aber ich fürchte eine Datenbankmigration wird genauso eine Katastrophe.

Dieses Thema nervt ungeheuerlich, auch weil es zwischenzeitlich so viel Raum im Alltag einnimmt, dass es unverhältnismässig ist.

[mhh]

.....

Das Ergebnis ist: Eine performante Nutzung ist nur möglich wenn Ifab abgeschaltet ist.

.....

Wenn das mal so einfach möglich wäre. IFAP lässt sich nicht abschalten. Sobald es auf dem Rechner installiert ist, weil man es hin und wieder benötigt, wird es gestartet.

[mhh]

Nachtrag: ich arbeite auf RDP, also keine lokale Installation! Keine Ahnung wie ich da IFAP an einzelnen Stationen los werden könnte.

[BaGo]

Nachtrag: ich arbeite auf RDP, also keine lokale Installation! Keine Ahnung wie ich da IFAP an einzelnen Stationen los werden könnte.

Bei RDP habe ich jetzt auch keine Idee, da quält sich alles übers Netz. Es bleibt schwierig mit Turbomed.

[McLeod]

Eigentlich ist genau das Gegenteil der Fall: Im RDP-Betrieb (Terminalserver) erfolgen alle DB- und Programmzugriffe lokal auf dem Server, das "schlechte Netzwerk" von "TM-Gurus" und TM-Verkaufsgesindel immer als schuldig an schlechter LahmoMed -Performance identifiziert, spielt hier praktisch keine Rolle.
Das heisst aber seit geraumer Zeit leider nicht mehr, dass die ganze Sache dann auch gut performt.

[pmortara]

Wie viele Stationen arbeiten denn per RDP auf dem Server? 4 Kerne und 16GB kommt mir etwas knapp dimensioniert vor. Evtl. hatte der alte Server da einfach etwas mehr Puffer und war deshalb gefühlt schneller.
In den Energie-Einstellungen des Servers bitte auch mal schauen, ob dort 'Höchstleistung' und nicht etwa 'Ausbalanciert' o.ä. ausgewählt ist, das hat bei vielen unserer Kunden schon gut geholfen.

[mhh]

Wie viele Stationen arbeiten denn per RDP auf dem Server? 4 Kerne und 16GB kommt mir etwas knapp dimensioniert vor. Evtl. hatte der alte Server da einfach etwas mehr Puffer und war deshalb gefühlt schneller.
In den Energie-Einstellungen des Servers bitte auch mal schauen, ob dort 'Höchstleistung' und nicht etwa 'Ausbalanciert' o.ä. ausgewählt ist, das hat bei vielen unserer Kunden schon gut geholfen.

Danke!

Es sind 8 Stationen, davon wird an 2 (max bis zu 3) Stationen gearbeitet. Das RAM ist zum alten Server unverändert 16GB. Laut Ressourcenmonitor knapp aber ausreichend (ca. 1 GB/Arbeitsplatz). Ich lasse morgen mal die Leistungsüberwachung mitlaufen für einige Zeit.

Genauso schalte ich morgen mal auf Höchstleistung, allerdings war das beim alten Server auch nicht der Fall, will das nur anmerken. Vielleicht ist WinServer 2016 auch viel mit sich alleine beschäftigt? Ich möchte nichts unversucht lassen.

[mhh]

Eigentlich ist genau das Gegenteil der Fall: Im RDP-Betrieb (Terminalserver) erfolgen alle DB- und Programmzugriffe lokal auf dem Server, das "schlechte Netzwerk" von "TM-Gurus" und TM-Verkaufsgesindel immer als schuldig an schlechter LahmoMed -Performance identifiziert, spielt hier praktisch keine Rolle.
Das heisst aber seit geraumer Zeit leider nicht mehr, dass die ganze Sache dann auch gut performt.

Vieles wird heute 'schlampig' programmiert. Ob die Schleife 100mal oder Millionenmal abgearbeitet werden muss, ist den Programmieren von heute keine Mühe mehr wert. Man schätzt dass einige Kohlekraftwerke weltweit eingespart werden könnten, wenn die Programmierung sauber erfolgen würde. Aber den Preis für diese Mühe will keiner mehr zahlen, bzw. lieber dafür etwas mehr Gewinn eintreichen.

[pmortara]

[quote="mhh"
Es sind 8 Stationen, davon wird an 2 (max bis zu 3) Stationen gearbeitet. Das RAM ist zum alten Server unverändert 16GB. Laut Ressourcenmonitor knapp aber ausreichend (ca. 1 GB/Arbeitsplatz). Ich lasse morgen mal die Leistungsüberwachung mitlaufen für einige Zeit.

Genauso schalte ich morgen mal auf Höchstleistung, allerdings war das beim alten Server auch nicht der Fall, will das nur anmerken. Vielleicht ist WinServer 2016 auch viel mit sich alleine beschäftigt? Ich möchte nichts unversucht lassen.[/quote]

Gerade IFAP braucht schon etwas mehr RAM, von daher könnte ich mit schon vorstellen, dass man da noch etwas nachlegen muss, aber irgendwie glaube ich auch nicht, dass der alleinige Grund ist.

Was die Energie-Einstellungen angeht: Da war m.E. früher auch ziemlich egal, fing aber vor ein paar Jahren damit an, dass immer mehr Praxen angerufen haben uns sich beschwerten, dass die Kassenabrechnung plötzlich so lahm sei, teilweise direkt nachdem wir einen Jahre alten Server gegen einen neuen getauscht haben. Möglicherweise hat Microsoft da per Update irgendwas geändert, wir haben es nie herausgefunden, stellen aber die Server jetzt immer schon bei Auslieferung auf 'Höchstleistung'