Erhebliche Performance-Probleme mit TM

[imb]

Hab gerade mal noch mit HD Tach die Geschwindigkeit der Client-Platten gemessen... 48 MB/s als durchschnittliche Lesegeschwindigkeit sind natürlich nicht so furchtbar viel...

[michael]

Also ich habe es eben mal beobachtet... Grenzwertig ist die CPU-Auslastung (die ein oder andere Wartesekunde kommt garantiert daher, Auslastung 96% etc). Ist ja schon bemerkenswert dass das Anzeigen einer Liste derart viel Rechenleistung beansprucht, ist immerhin ein AMD 64 3000+ CPU...

Habe gerade einen Altrechner laufen lassen PIII 500Mhz, 128 RAM, randvolle HD: Bei Tagesliste bzw. Behandlungsfallzahlen bewegt sich die CPU Auslastung um die 50%, einzelne Spitzen bis 70%.

Haben Sie einen Virenscanner laufen?? Bei uns waren es die letzten Ifap's, die die Rechner an ihre Grenzen gebracht haben?!!!

Mfg

Pätzold

[imb]

Ne, da läuft kein Virenscanner... Ich hab beim Test-Arbeiten, also typische, alltägliche Arbeitsschritte mal den Taskmanager offen gelassen und die CPU Auslastung über eine längere Zeit beobachtet... Da waren einige Peaks dazwischen, die in der Form nicht sein müssen... So vom Bauchgefühl her würde ich schon sagen, dass man hier mit einem insgesamt flotteren System (hier spielen ja einige Faktoren eine Rolle, CPU, Chipsatz, HDDs usw.) schon noch ein etwas schnelleres Arbeiten ermöglichen kann. Unterm Strich hilft hier wahrscheinlich eh nur Trial&Error....

[schmidt-dietrich]

Wir haben durchweg mindestens 1GB RAM, gigabit-Lan und z.T. 3GB-RAM an den Clients; entscheidend waren wirklich diese ganzen Hintergrund TM Spieleren auszuschalten, dann werden die Hänger deutlich wenige rund Performance
steigt fühlbar!
Echt angenehm!
Auffallend ist dann das ifap sich einiges an Leistung krallt..

Manchmal hilt bei viel Hängen kruz mal alle Clients beenden und Server restarten dann flutschts wieder, wobei ich nicht sicher bin ob nicht einfach (andererThread?) der Dienst fastObjects restartet werden könnte?
Frage an die Kollegen dazu.... ?

[imb]

Das Netzwerk läuft bei uns noch auf 100MBit-Basis, hier wäre allerdings nur der Switch zu tauschen...
Jedoch hab ich gestern auch die Netzwerkauslastung beim Arbeiten überprüft, das war äußerst gering... es gehen hier ja ohnehin keine großen Datenmengen durch die Leitung.

[Michael.Lueb]

Habe auch gewaltige Langsamkeitsprobleme. Ping zum Server ist 0 msec. Es liegt auch nicht an der Festplattengeschwindigkeit oder an anderen Hardwareschwächen. Natürlich gibts einen Unterschied zwischen langsameren und schnelleren Rechnern. Doch darin liegt nicht das Problem.
Es liegt wohl in der Turbomed-Programmierung bzw. in der implementierten Datenbank.
Namenssuche mit 1 Buchstaben ca. 5 sec.
Rezeptaufruf mit F8 ca. 5 sec.
ESC nach Blättern in der Karteikarte von sofort bis ca. 1 Minute (Alles-oder Nichts-Prinzip)
Blättern in der Laborauftragsliste: biestig (eigentlich eher boshaft) langsam
Aufrufen der Laborkarte ca. 10 sec - blättern darin: ebenfalls biestig langsam
Fast alle Funktionen zu langsam
Man sollte sich Geschwindigkeitsmäßig an Microsoft-Programmen orientieren. Diese (WORD oder EXCEL) sind äußerst schnell.
Man sieht also, dass es machbar ist. Die Probleme liegen also wohl eher bei der Programmierinsuffizienz bei TurboMed.
Möglicherweise spielt das ebenso biestig langsame IFAP-Praxis-Center auch eine verlangsamende Rolle.
Da haben sich zwei gefunden.....

Da aber wohl keine ernsthafte Ausweichmöglichkeit besteht und die Ärzte insgesamt sehr duldsam sind, ist m.E. mit einer Verbesserung nicht zu rechnen.

[Snailmed]

Hallo,

ich kann nur zustimmen, dass die Programmroutinen von Turbomed einfach viel zu bremsend programmiert wurden.
Wie bereits von anderen Forenteilnehmern erwähnt, haben andere Programme mit gleicher Komplexität deutlich bessere
Features und funktionieren flüssiger. Es ist so oder so schon eine maßlose Unverschämheit, dass Turbomed ein totaler Ressourcenfresser ist und die Programmstruktur bei den bisherigen Version beibehalten hat. Bei der heutigen Datenmenge und den neuen "überaus hilfreichen" Features ist Turbomed eigentlich dazu verpflichtet auch das Programm selbst daran anzupassen.
Eine Softwarefirma kann einfach nicht erwarten, dass Ärzte haufenweise Geld ausgeben für Hardware, damit ein Programm, dass viel effizienter laufen könnte (schließlich klappt es bei so vielen anderen Firmen und Programmen), auch nur ansatzweise funktioniert. Sich auf der Bequemlichkeit auszuruhen, dass man früher vielleicht mal das schnellse Programm war, ist einfach lächerlich!

Ich glaube nicht, dass Turbomed schon multiple CPU-Unterstützung hat; bei solchen wirklichen nützlichen Features tut sich Turbomed ja sonst auch sehr schwer!

Mfg

PS: Ui, Dell ist immer eine recht teure Sache... lieber selber zusammenstellen?

[Johnny]

Hallo zusammen,

hatte vor kurzem ähliche Probleme, s.http://www.vondoczudoc.de/viewtopic.php ... t=15#p9465.

Überprüfen Sie doch mal die Einstellungen in der Benutzeinstellung.

Gruß aus KIel

Johnny

[imb]

Hallo zusammen,

hatte vor kurzem ähliche Probleme, s.http://www.vondoczudoc.de/viewtopic.php ... t=15#p9465.

Überprüfen Sie doch mal die Einstellungen in der Benutzeinstellung.

Gruß aus KIel

Johnny

Danke für den Hinweis. Hier arbeiten alle Arbeitsstationen mit einem gemeinsamen User "Praxis". Ein Arzt-Benutzer existiert zwar, jedoch wird dieser nur für besondere Korrekturfälle oder Abrechnung benötigt.

[imb]

Achso, die Einstellung ist auch richtig gesetzt entsprechend ihres Postings...

[imb]

Ich habe hier mal einen Anfang gemacht, um Optimierungsmöglichkeiten in TM zusammenzufassen:
http://vondoczudoc-wiki.oblomov.de/doku ... ptimierung

So ist für jeden direkt ersichtlich, welche Möglichkeiten derzeit bestehen... das ist übersichtlicher und geht schneller als hier im Forum zu suchen....

Wie auch im Artikel vermerkt, möchte ich ausdrücklich betonen, dass ich mir dabei keine Ideen zu eigen machen will! Es ist eine Zusammenfassung der hier genannten Möglichkeiten.

To be continued!

[schmidt-dietrich]

Auf meine Anfrage - weil ja der Server neuaufgesetzt wird (siehe alte Threads) wie es mit Multicore und RAM-Unterstützung aussieht kam aus Kile nur das man sich doch bitte an den TM-PArtner wenden soll...!
*Blödsinn* ich habe mir mal erlaubt zu antworten, das Sie eigentlich genau wissen müßten welche Hardwareanforderungen Ihr Programm hat und es entsprechend auch mit neueren Systemen auch mal testen sollten...
Ergebnis keine Antwort.
Schade. Das hat den etwas positiveen Eindruck wieder getrübt.

[imb]

Auf meine Anfrage - weil ja der Server neuaufgesetzt wird (siehe alte Threads) wie es mit Multicore und RAM-Unterstützung aussieht kam aus Kile nur das man sich doch bitte an den TM-PArtner wenden soll...!
*Blödsinn* ich habe mir mal erlaubt zu antworten, das Sie eigentlich genau wissen müßten welche Hardwareanforderungen Ihr Programm hat und es entsprechend auch mit neueren Systemen auch mal testen sollten...
Ergebnis keine Antwort.
Schade. Das hat den etwas positiveen Eindruck wieder getrübt.

Ich habe dazu gerade einen Beitrag aus dem Entwicklerforumvom FastObjects Server gefunden:

the FastObjects Server is licensed for one CPU per default.
If want to run the FastObjects Server or a FastObjects application on a multi-processor machine you need an additional license for more CPUs.
One dual core processor is counted as two physical processors.

Ich gehe also einfach mal davon aus, dass TM nur eine einfache Lizenz ein- bzw. weiterverkauft. Demnach haben wir auch keine Multi-Core Unterstützung....

[imb]

Achso, 64-bit wird auch nicht unterstützt... der FastObjects Server läuft auf meinem Win Server 2003 x64 im 32bit Modus...

[schmidt-dietrich]

aha,
schade...
das wären wirklich praktische Dinge - aber auf mittelfristige Sicht wird da TM auch nicth dranvorbeikommen, denn mit den ganzen Balastanwendungen, macht es durchaus Sinn das die Aufgaben/Tasks auf den versch. Kernen laufen könnten.
Tja.

[imb]

hm... laut diesem technischen Handbuch gibt es doch eine Möglichkeit, eine Multicore-Unterstützung zu aktivieren:

http://foox.at/htl/20052006/Versant/Fas ... Guides.pdf
Seite 336

ptserver.cfg:
concurrencyLevel=9

Hat jemand eine Idee, wie man die DB entsprechend fordern kann, sodass der Unterschied sichtbar würde?
Gibt es Log-Dateien zum DB-Server, aus denen man entnehmen könnte, ob nun tatsächlich eine Mukticore-Unterstützung läuft?

[imb]

Also die Tatsache, dass bei einer "Datenbank prüfen"-Aktion der Prozess FastObjects Server eine CPU Auslastung von genau 25% erreicht, lässt bei einem Quad-Core-Prozessor die Vermutung aufkommen, dass die Multicore-Unterstützung im Rahmen der TM-Lizenz nicht funktioniert. Sonst würde er ja weitere Ressourcen in Anspruch nehmen, die über das Viertel (= ein Kern) hinausgehen...

[FranzKonrad]

Achso, 64-bit wird auch nicht unterstützt... der FastObjects Server läuft auf meinem Win Server 2003 x64 im 32bit Modus...

Hallo,

ja, ja, deswegen halte ich den Rat zum 64Bit Server für etwas fraglich, zumal 32Bit-Programme ja nicht direkt im 64-Bit-Windows laufen können, sondern eine 32-Bit Windows-Emulation brauchen (die dann dem Programm eigentlich auch nur weniger als 4GByte Speicher anbieten kann!). Und ob diese Emulation dann die volle Performance bringt?

Hat jemand eine Idee, wie man die DB entsprechend fordern kann, sodass der Unterschied sichtbar würde?
Gibt es Log-Dateien zum DB-Server, aus denen man entnehmen könnte, ob nun tatsächlich eine Mukticore-Unterstützung läuft?

StrgAltDel: WindowsTaskManager (Reiter Systemleistung) ggf. umstellen mit -> Ansicht -> CPU-Verlauf -> Ein Diagramm pro CPU
Dann was laufen lassen und die CPU-Auslastungsgrafik beobachten.


Gruß

FranzKonrad
Ich kanns auf dem Server nicht machen, da hier noch mein alter Server mit Einkernprozessor in Betrieb ist, auf einem XP-Client hab ichs gerade probiert: F8 beim Patienten hat die CPU 1 belastet, ein Statistiklauf die CPU 2. Gleichzeitig geht allerdings bei Turbomed nichts, mir fällt jedenfalls nichts ein. Fastobjects läuft halt auf dem Client nicht.
-> also, nur zu, probieren und berichten.

[imb]

Hat jemand eine Idee, wie man die DB entsprechend fordern kann, sodass der Unterschied sichtbar würde?
Gibt es Log-Dateien zum DB-Server, aus denen man entnehmen könnte, ob nun tatsächlich eine Mukticore-Unterstützung läuft?

StrgAltDel: WindowsTaskManager (Reiter Systemleistung) ggf. umstellen mit -> Ansicht -> CPU-Verlauf -> Ein Diagramm pro CPU
Dann was laufen lassen und die CPU-Auslastungsgrafik beobachten.

Jep, ist mir bekannt. Es schlagen zwar alle Graphen (unterschiedlich stark) aus, aber die Gesamtbelastung überschreitet 25% nicht.
Das Verhalten ist übrigens mit und ohne diesem Eintrag in der cfg-Datei identisch. Ich vermute fast, dass diese Option zu einer älteren FastObjects-Server Version gehört (Das Handbuch ist ja von 2005/06).

Ich kanns auf dem Server nicht machen, da hier noch mein alter Server mit Einkernprozessor in Betrieb ist, auf einem XP-Client hab ichs gerade probiert: F8 beim Patienten hat die CPU 1 belastet, ein Statistiklauf die CPU 2. Gleichzeitig geht allerdings bei Turbomed nichts, mir fällt jedenfalls nichts ein. Fastobjects läuft halt auf dem Client nicht.
-> also, nur zu, probieren und berichten.

Habe gerade TM mal auf dem Server gestartet, da beschränkt sich das Programm auf einen Kern. (Egal ob F8 oder Statistiken)

[imb]

So... der neue PC ist da und eingerichtet. TM läuft darauf schon eine ganze Ecke schneller, keine Frage. Die Geschwindigkeit liegt irgendwo zwischen dem alten PC und dem Terminalserver-Zugriff, welcher natürlich unschlagbar schnell ist. Soll heißen: Nun ist der noch übrig gebliebene Flaschenhals bei den Datenbank-Zugriffen zu suchen...