10
Macht die Umstellung auf Gigabit-LAN Sinn? Performance-Gewinn?
Hallo,
ganz kurz die Rahmenbedingungen:
Es geht um eine Arztpraxis mit 1 Server und 9 Clients.
Als Server kommt zum Einsatz:
- Windows Server 2003 x64
- Hardware: Intel Core 2 Quad Q9350, Intel Entry Server Board S3210SHLC, 8 GB RAM, 2x Samsung SpinPoint F1 RAID 750GB SATA II (HE753LJ),
2x Samsung SpinPoint F1 RAID 320GB SATA II (HE322HJ), Festplatten sind nicht als Raid konfiguriert
Clients sind 8x Marke-Eigenbau (Win XP Pro mit AMD 64 2800+, Aus K8N nForce 3, 1GB RAM) und ein neuer Dell Optiplex 760 (WinXP, E8400, 4GB RAM...)
In der Praxis wird ausschließlich mit der Praxissoftware gearbeitet. Der Server läuft als DC, außerdem werkelt dort die FastObjects-DB der Praxissoftware.
Es gibt sonst auch keinen weiteren Traffic - also eigentlich dürften sich alle beteiligten Geräte nur langweilen.
Als Switch ist ein 3Com 100Mbit 24-Port Switch im Einsatz, genaue Bezeichnung müsste ich erst nachschauen. Jedenfalls nicht managebar...
Problem:
Die kämpfen aufgrund vieler unsinniger Module, die ihnen der Softwarehersteller aufzwingt, ein wenig mit der Performance.
Ein Problem wurde schnell lokalisiert - die Hardware der Clients ist einfach etwas in die Jahre gekommen... der neue Dell-Client ist schon wesentlich perfomanter...
Nun gibt es in diversen Foren zur besagten Software Hinweise, dass die Umstellung auf Gigabit-LAN erhebliche Performance-Gewinne bringen soll...
Nun frage ich mich, ob da was dran sein kann? Wenn ich die Netzwerkauslastung über den Taskmanager während des normalen Praxisbetriebes beobachte, dann sind das immer <1-5%, meist im 0,x Bereich.
Was bringt da die Umrüstung auf GigabitLAN?
(Der neue Switch wäre weniger das Problem, allerdings müsste erstmal geprüft werden, ob die Kabel das noch mitmachen... )
Gibt es Möglichkeiten, hier irgendwelche Abschätzungen zu treffen?
Nach einiger Suche im Internet bin ich auf die Tools IPerf und NetIO gestoßen.
Hier mal die Ergebnisse (Clientseite, Dell 760):
S:\Software\IPerf>iperf -c 192.168.0.1
Client connecting to 192.168.0.1, TCP port 5001
TCP window size: 8.00 KByte (default)
[1912] local 192.168.0.10 port 1194 connected with 192.168.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[1912] 0.0-10.0 sec 99.9 MBytes 83.8 Mbits/sec
S:\Software\NetIO\bin>win32-i386 -t 192.168.0.1
NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel
TCP connection established.
Packet size 1k bytes: 11424 KByte/s Tx, 11312 KByte/s Rx.
Packet size 2k bytes: 11425 KByte/s Tx, 11322 KByte/s Rx.
Packet size 4k bytes: 11570 KByte/s Tx, 11526 KByte/s Rx.
Packet size 8k bytes: 11573 KByte/s Tx, 11518 KByte/s Rx.
Packet size 16k bytes: 11600 KByte/s Tx, 11528 KByte/s Rx.
Packet size 32k bytes: 11614 KByte/s Tx, 11558 KByte/s Rx.
Done.
S:\Software\NetIO\bin>win32-i386 -u 192.168.0.1
NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel
UDP connection established.
Packet size 1k bytes: 11470 KByte/s (0%) Tx, 11467 KByte/s (0%) Rx.
Packet size 2k bytes: 5909 KByte/s (0%) Tx, 8219 KByte/s (0%) Rx.
Packet size 4k bytes: 11688 KByte/s (0%) Tx, 11641 KByte/s (0%) Rx.
Packet size 8k bytes: 11680 KByte/s (0%) Tx, 11697 KByte/s (0%) Rx.
Packet size 16k bytes: 11699 KByte/s (0%) Tx, 11676 KByte/s (0%) Rx.
Packet size 32k bytes: 11729 KByte/s (0%) Tx, 11681 KByte/s (0%) Rx.
Done.
Bin für alle Tipps und Meinungen dankbar!!
ganz kurz die Rahmenbedingungen:
Es geht um eine Arztpraxis mit 1 Server und 9 Clients.
Als Server kommt zum Einsatz:
- Windows Server 2003 x64
- Hardware: Intel Core 2 Quad Q9350, Intel Entry Server Board S3210SHLC, 8 GB RAM, 2x Samsung SpinPoint F1 RAID 750GB SATA II (HE753LJ),
2x Samsung SpinPoint F1 RAID 320GB SATA II (HE322HJ), Festplatten sind nicht als Raid konfiguriert
Clients sind 8x Marke-Eigenbau (Win XP Pro mit AMD 64 2800+, Aus K8N nForce 3, 1GB RAM) und ein neuer Dell Optiplex 760 (WinXP, E8400, 4GB RAM...)
In der Praxis wird ausschließlich mit der Praxissoftware gearbeitet. Der Server läuft als DC, außerdem werkelt dort die FastObjects-DB der Praxissoftware.
Es gibt sonst auch keinen weiteren Traffic - also eigentlich dürften sich alle beteiligten Geräte nur langweilen.
Als Switch ist ein 3Com 100Mbit 24-Port Switch im Einsatz, genaue Bezeichnung müsste ich erst nachschauen. Jedenfalls nicht managebar...
Problem:
Die kämpfen aufgrund vieler unsinniger Module, die ihnen der Softwarehersteller aufzwingt, ein wenig mit der Performance.
Ein Problem wurde schnell lokalisiert - die Hardware der Clients ist einfach etwas in die Jahre gekommen... der neue Dell-Client ist schon wesentlich perfomanter...
Nun gibt es in diversen Foren zur besagten Software Hinweise, dass die Umstellung auf Gigabit-LAN erhebliche Performance-Gewinne bringen soll...
Nun frage ich mich, ob da was dran sein kann? Wenn ich die Netzwerkauslastung über den Taskmanager während des normalen Praxisbetriebes beobachte, dann sind das immer <1-5%, meist im 0,x Bereich.
Was bringt da die Umrüstung auf GigabitLAN?
(Der neue Switch wäre weniger das Problem, allerdings müsste erstmal geprüft werden, ob die Kabel das noch mitmachen... )
Gibt es Möglichkeiten, hier irgendwelche Abschätzungen zu treffen?
Nach einiger Suche im Internet bin ich auf die Tools IPerf und NetIO gestoßen.
Hier mal die Ergebnisse (Clientseite, Dell 760):
S:\Software\IPerf>iperf -c 192.168.0.1
Client connecting to 192.168.0.1, TCP port 5001
TCP window size: 8.00 KByte (default)
[1912] local 192.168.0.10 port 1194 connected with 192.168.0.1 port 5001
[ ID] Interval Transfer Bandwidth
[1912] 0.0-10.0 sec 99.9 MBytes 83.8 Mbits/sec
S:\Software\NetIO\bin>win32-i386 -t 192.168.0.1
NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel
TCP connection established.
Packet size 1k bytes: 11424 KByte/s Tx, 11312 KByte/s Rx.
Packet size 2k bytes: 11425 KByte/s Tx, 11322 KByte/s Rx.
Packet size 4k bytes: 11570 KByte/s Tx, 11526 KByte/s Rx.
Packet size 8k bytes: 11573 KByte/s Tx, 11518 KByte/s Rx.
Packet size 16k bytes: 11600 KByte/s Tx, 11528 KByte/s Rx.
Packet size 32k bytes: 11614 KByte/s Tx, 11558 KByte/s Rx.
Done.
S:\Software\NetIO\bin>win32-i386 -u 192.168.0.1
NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel
UDP connection established.
Packet size 1k bytes: 11470 KByte/s (0%) Tx, 11467 KByte/s (0%) Rx.
Packet size 2k bytes: 5909 KByte/s (0%) Tx, 8219 KByte/s (0%) Rx.
Packet size 4k bytes: 11688 KByte/s (0%) Tx, 11641 KByte/s (0%) Rx.
Packet size 8k bytes: 11680 KByte/s (0%) Tx, 11697 KByte/s (0%) Rx.
Packet size 16k bytes: 11699 KByte/s (0%) Tx, 11676 KByte/s (0%) Rx.
Packet size 32k bytes: 11729 KByte/s (0%) Tx, 11681 KByte/s (0%) Rx.
Done.
Bin für alle Tipps und Meinungen dankbar!!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 124282
Url: https://administrator.de/forum/macht-die-umstellung-auf-gigabit-lan-sinn-performance-gewinn-124282.html
Ausgedruckt am: 22.12.2024 um 17:12 Uhr
10 Kommentare
Neuester Kommentar
Zitat von @osterhase09:
Als Server kommt zum Einsatz:
- Windows Server 2003 x64
- Hardware: Intel Core 2 Quad Q9350, Intel Entry Server Board
S3210SHLC, 8 GB RAM, 2x Samsung SpinPoint F1 RAID 750GB SATA II
(HE753LJ),
2x Samsung SpinPoint F1 RAID 320GB SATA II (HE322HJ), Festplatten
sind nicht als Raid konfiguriert
Clients sind 8x Marke-Eigenbau (Win XP Pro mit AMD 64 2800+, Aus K8N
nForce 3, 1GB RAM) und ein neuer Dell Optiplex 760 (WinXP, E8400, 4GB
RAM...)
Als Server kommt zum Einsatz:
- Windows Server 2003 x64
- Hardware: Intel Core 2 Quad Q9350, Intel Entry Server Board
S3210SHLC, 8 GB RAM, 2x Samsung SpinPoint F1 RAID 750GB SATA II
(HE753LJ),
2x Samsung SpinPoint F1 RAID 320GB SATA II (HE322HJ), Festplatten
sind nicht als Raid konfiguriert
Clients sind 8x Marke-Eigenbau (Win XP Pro mit AMD 64 2800+, Aus K8N
nForce 3, 1GB RAM) und ein neuer Dell Optiplex 760 (WinXP, E8400, 4GB
RAM...)
*KOPFSCHÜTTEL* *KOPFSCHÜTTEL* *KOPFSCHÜTTEL* *KOPFSCHÜTTEL*
In der Praxis wird ausschließlich mit der Praxissoftware
gearbeitet. Der Server läuft als DC, außerdem werkelt dort
die FastObjects-DB der Praxissoftware.
Es gibt sonst auch keinen weiteren Traffic - also eigentlich
dürften sich alle beteiligten Geräte nur langweilen.
Als Switch ist ein 3Com 100Mbit 24-Port Switch im Einsatz, genaue
Bezeichnung müsste ich erst nachschauen. Jedenfalls nicht
managebar...
Problem:
Kämpfen mit der Performance
Wenn schon ein Win2k3 Server läuft, packt nen Terminal Server drauf und ersetzt die Clients durch "FSC FUTRO B100", Kostenpunkt ~50EUR/Stück oder "FSC Futro S300" für ~70EUR/Stück. Beides jeweils über gewerbliche Ebayverkäufer, also mit den "normalen" Gewährleistungszeiträumen. Des Weiteren dürfte eine TS Architektur weitaus kostengünstiger(z.B. Strom) sein.
Über die TSs, werden auch keine großen Daten durch die Weltgeschichte geschaufelt. Das haben wir mit ~200 Arbeitsplätzen im Haus im Einsatz und rennt super.
Ein Problem wurde schnell lokalisiert - die Hardware der Clients ist einfach
etwas in die Jahre gekommen... der neue Dell-Client ist schon wesentlich perfomanter...
etwas in die Jahre gekommen... der neue Dell-Client ist schon wesentlich perfomanter...
Also die Software will ich sehen bei der für eine Praxissoftware die Ausstattung der AMD Kisten nicht ausreichen soll?? Wenn die Software echt so Ressourcenfressend ist würde ich
eher anraten den Anbieter zu wechseln als die eigene Hardware dem Ressourcenschwund anzupassen.
Eine Umstellung auf komplett Gigabit halte ich für nicht Sinnvoll da Clientseitig nie eine solche Bandbreite ausgenutzt werden kann. Eine Serverseitige Anbindung im Gigabitbereich ist bei Ordentlichen Servern auch Hardwareseitig so Ausgelegt das diese genutzt werden können. Deswegen glaube ich nicht das Gigabit hier Performance bringen wird.
Bei der Hardwareauflistung muss ich aber bissel den Kopf schütteln alles bissel zusammengeschustert und ein Server ohne Raid ist schon Fahrlässig.
Eine Software bei der Clientseitig solch eine Hardware nicht Ausreicht ist entweder "###e" (sry) oder die Aussage des Herstellers das es das Problem sein soll das er nicht weiss woran es liegt. Dann müssten die Clients immer auf 100% Last laufen.
Frag doch mal andere Praxen mit solcher Software ob sie ähnliche Probleme haben.
MFG
Gansa29
Bei der Hardwareauflistung muss ich aber bissel den Kopf schütteln alles bissel zusammengeschustert und ein Server ohne Raid ist schon Fahrlässig.
Eine Software bei der Clientseitig solch eine Hardware nicht Ausreicht ist entweder "###e" (sry) oder die Aussage des Herstellers das es das Problem sein soll das er nicht weiss woran es liegt. Dann müssten die Clients immer auf 100% Last laufen.
Frag doch mal andere Praxen mit solcher Software ob sie ähnliche Probleme haben.
MFG
Gansa29
guten abend,
welche praxissoftware soll denn das sein ?
gruß
o.
welche praxissoftware soll denn das sein ?
gruß
o.
Danke schonmal für die schnellen Reaktionen.
Das bei dem Kunden Hardwaretechnisch alles noch nach Baustelle aussieht, ist mir bewusst und entsprechende Maßnahmen sind schon eingeleitet worden. Das möchte ich hier aber nicht zum Kern der Diskussion machen. Die Hardwareauflistung hatte ich nur gemacht, um eine technische Grundlage zum Bewerten der Situation zu liefern...
Der Hersteller gibt die Mindestanforderung der Clients an mit Pentium-CPU ab 2 Ghz und min. 1 GB RAM. Und das ist, so unglaublich das klingen mag, auch tatsächlich ernst gemeint. Drunter läuft da garnichts!... Wenn man sich mal eine halbe Stunde mit der Software beschäftigt,wird auch schnell klar warum. Überall Werbeeinblendungen, Routinen, die irgendwelche sinnlosen Verknüpfungen in der Medikamentendatenbank suchen usw... Nunja, die Software ist halt günstig im Unterhalt.... und genauso "billig" auch programmiert...
Andere Praxen kämpfen genau so mit Performance-Problemen... in den entsprechenden Foren werden schon Möglichkeiten diskutiert, bestimmte unbenötigte und überflüssige Module durch Umbenennen von DLL Dateien "abzuschalten" (bzw. ein Starten zu verhindern...), weil sich der Hersteller nicht darum kümmert und der Arbeitsablauf extrem gebremst wird (6-10 Sekunden Wartezeit um eine Patientenakte aufzurufen ist einfach nicht akzeptabel, so als Beispiel).
Auf dem neuen Dell-Client ist die Performance aber schon auf einem Niveau, mit dem der Kunde gut leben könnte... mehr muss also nicht zwingend. Nur für die anderen alten Kisten, muss man sich eben nun was einfallen lassen...
Soweit noch mal ein paar Hintergrundinfos, die Software ist TurboMed.
Zu euren Vorschlägen:
- Terminal Server: Die Idee hatte ich im Zuge einiger Maßnahmen, die in Kürze am Server anstehen, auch schon (Stichwort: HDDs als Raid usw.). Das ganze habe ich auch schon eine Woche an einem Arbeitsplatz im Testbetrieb laufen gehabt - Rückmeldung des Kunden war sehr positiv: Deutlich schneller als die AMD-Clients, der Geschwindigkeitsunterschied zum Dell ist aber eher minimal.
Man wird aber nicht ohne weiteres alle Arbeitsplätze auf den TS-Betrieb umstellen können, da einige medizinische Geräte angebunden werden müssen... Klar, eine serielle Schnittstelle kann man auch mal durchreichen etc, aber hier sind auch noch Framegrabber-Karten und andere Dinge im Spiel... Ein Problemloser Umstieg auf TS wäre an ca. 4 Clients möglich (hier ausschließlich Schreibtischarbeit)
- TS auf einem DC ist ja eher problematisch, sprich hier müsste zusätzliche Hardware her... oder das ganze virtualisieren auf einem Host? Reicht die Hardware dann noch? Das Serversystem macht auf mich einen ausgesprochen flotten Eindruck! Subjektiv jedenfalls besser, als die zusammengewürfelte Hardware vermuten lässt....
- Auffällig bei der Praxissoftware auf den AMD Clients sind die häufigen Zugriffe auf die lokale Festplatte. Testweise habe ich an 2 Clients den RAM auf 2 GB aufgerüstet, wodurch es minimal besser wurde... aber CPU Auslastung und HDD Zugriffe sprechen eine deutliche Sprache!
- Nach einiger Recherche (der Hersteller ist nicht sehr auskunftsfreudig) habe ich herausbekommen, dass der DB-Server weder 64-bit fähig ist, noch eine Multi-Core-Unterstützung hat.... (Technisch kann FastObjects das schon, aber das ist eine Lizenzgeschichte mit dem Hersteller von TM) --> Hier kann man also im Prinzip nichts weiter tun
Nunja, das ist alles rangieren in sehr beschränktem Raum - das gilt fürs Budget, wie für die Unterstützung des Herstellers als auch die vorhandene Hardware.... Auf der anderen Seite ist die Größenordnung <10 Clients ja auch eher in dem Bereich, wo viele andere Praxen noch den "WindowsXP-Server" nebenzu als Arbeitsplatz nutzen....alles schon gesehen...
Das bei dem Kunden Hardwaretechnisch alles noch nach Baustelle aussieht, ist mir bewusst und entsprechende Maßnahmen sind schon eingeleitet worden. Das möchte ich hier aber nicht zum Kern der Diskussion machen. Die Hardwareauflistung hatte ich nur gemacht, um eine technische Grundlage zum Bewerten der Situation zu liefern...
Der Hersteller gibt die Mindestanforderung der Clients an mit Pentium-CPU ab 2 Ghz und min. 1 GB RAM. Und das ist, so unglaublich das klingen mag, auch tatsächlich ernst gemeint. Drunter läuft da garnichts!... Wenn man sich mal eine halbe Stunde mit der Software beschäftigt,wird auch schnell klar warum. Überall Werbeeinblendungen, Routinen, die irgendwelche sinnlosen Verknüpfungen in der Medikamentendatenbank suchen usw... Nunja, die Software ist halt günstig im Unterhalt.... und genauso "billig" auch programmiert...
Andere Praxen kämpfen genau so mit Performance-Problemen... in den entsprechenden Foren werden schon Möglichkeiten diskutiert, bestimmte unbenötigte und überflüssige Module durch Umbenennen von DLL Dateien "abzuschalten" (bzw. ein Starten zu verhindern...), weil sich der Hersteller nicht darum kümmert und der Arbeitsablauf extrem gebremst wird (6-10 Sekunden Wartezeit um eine Patientenakte aufzurufen ist einfach nicht akzeptabel, so als Beispiel).
Auf dem neuen Dell-Client ist die Performance aber schon auf einem Niveau, mit dem der Kunde gut leben könnte... mehr muss also nicht zwingend. Nur für die anderen alten Kisten, muss man sich eben nun was einfallen lassen...
Soweit noch mal ein paar Hintergrundinfos, die Software ist TurboMed.
Zu euren Vorschlägen:
- Terminal Server: Die Idee hatte ich im Zuge einiger Maßnahmen, die in Kürze am Server anstehen, auch schon (Stichwort: HDDs als Raid usw.). Das ganze habe ich auch schon eine Woche an einem Arbeitsplatz im Testbetrieb laufen gehabt - Rückmeldung des Kunden war sehr positiv: Deutlich schneller als die AMD-Clients, der Geschwindigkeitsunterschied zum Dell ist aber eher minimal.
Man wird aber nicht ohne weiteres alle Arbeitsplätze auf den TS-Betrieb umstellen können, da einige medizinische Geräte angebunden werden müssen... Klar, eine serielle Schnittstelle kann man auch mal durchreichen etc, aber hier sind auch noch Framegrabber-Karten und andere Dinge im Spiel... Ein Problemloser Umstieg auf TS wäre an ca. 4 Clients möglich (hier ausschließlich Schreibtischarbeit)
- TS auf einem DC ist ja eher problematisch, sprich hier müsste zusätzliche Hardware her... oder das ganze virtualisieren auf einem Host? Reicht die Hardware dann noch? Das Serversystem macht auf mich einen ausgesprochen flotten Eindruck! Subjektiv jedenfalls besser, als die zusammengewürfelte Hardware vermuten lässt....
- Auffällig bei der Praxissoftware auf den AMD Clients sind die häufigen Zugriffe auf die lokale Festplatte. Testweise habe ich an 2 Clients den RAM auf 2 GB aufgerüstet, wodurch es minimal besser wurde... aber CPU Auslastung und HDD Zugriffe sprechen eine deutliche Sprache!
- Nach einiger Recherche (der Hersteller ist nicht sehr auskunftsfreudig) habe ich herausbekommen, dass der DB-Server weder 64-bit fähig ist, noch eine Multi-Core-Unterstützung hat.... (Technisch kann FastObjects das schon, aber das ist eine Lizenzgeschichte mit dem Hersteller von TM) --> Hier kann man also im Prinzip nichts weiter tun
Nunja, das ist alles rangieren in sehr beschränktem Raum - das gilt fürs Budget, wie für die Unterstützung des Herstellers als auch die vorhandene Hardware.... Auf der anderen Seite ist die Größenordnung <10 Clients ja auch eher in dem Bereich, wo viele andere Praxen noch den "WindowsXP-Server" nebenzu als Arbeitsplatz nutzen....alles schon gesehen...
Hallo,
wenn du die Clients schon als Problem ausgemacht hast, dann verstehe ich nicht wieso du das Netzwerk updaten willst? Wenn die PCs nicht mehr zeitgemäss sind musst du die wohl austauschen. Gute Arbeitsplatz PCs (z.b bei Dell, HP, etc) sind eigentlich immer optimal zusammengestellt und support gibts auch noch. Ich würde mir das nie antun, da mit selbstgebauten PCs zu arbeiten. Da geht schnell mal was hier oder dort kaputt, und der Aufwand für dich steigt enorm. Da rentiert sich der Aufwand für einen Wartungsvertrag doch schon enorm.
Vielleicht wäre ja auch ein Leasing für dich interessant, wenn die Anschaffung von 8 neuen PCs zu teuer ist.
wenn du die Clients schon als Problem ausgemacht hast, dann verstehe ich nicht wieso du das Netzwerk updaten willst? Wenn die PCs nicht mehr zeitgemäss sind musst du die wohl austauschen. Gute Arbeitsplatz PCs (z.b bei Dell, HP, etc) sind eigentlich immer optimal zusammengestellt und support gibts auch noch. Ich würde mir das nie antun, da mit selbstgebauten PCs zu arbeiten. Da geht schnell mal was hier oder dort kaputt, und der Aufwand für dich steigt enorm. Da rentiert sich der Aufwand für einen Wartungsvertrag doch schon enorm.
Vielleicht wäre ja auch ein Leasing für dich interessant, wenn die Anschaffung von 8 neuen PCs zu teuer ist.
ja, ist richtig. Die Netzwerkfrage kam nur in dem Zusammenhang auf, dass dies eben (laut Berichten) auch ein "Bremsklotz" sein soll und mit Gigabit-LAN in anderen Praxen im vorher/nachher-Vergleich alles viel schneller sein soll... das kann ich mir aus technischer Sicht aber irgendwie nicht erklären?! daher die konkrete Nachfrage in diese Richtung. (Wenn es hierfür eine Erklärung gibt, wäre ja auch der Dell Client noch perfomanter zu bekommen...)
Möchte diesen Aspekt bei den Planungen eben nicht unberücksichtigt lassen.
Möchte diesen Aspekt bei den Planungen eben nicht unberücksichtigt lassen.
Hi,
was willst du mit Gigabit anfangen, wenn der Switch nur 100 MBit unterstützt und die Netzwerkkarten wahrscheinlich auch? Bei dem "paar Bytes" an Traffic, die da in der Praxis erzeugt werden, langweilt sich doch die bestehende Hardware schon.
Überzeuge deinen Kunden davon, dass seine Praxissoftware offenbar Schrott ist.
was willst du mit Gigabit anfangen, wenn der Switch nur 100 MBit unterstützt und die Netzwerkkarten wahrscheinlich auch? Bei dem "paar Bytes" an Traffic, die da in der Praxis erzeugt werden, langweilt sich doch die bestehende Hardware schon.
Überzeuge deinen Kunden davon, dass seine Praxissoftware offenbar Schrott ist.
Also selbst wenn 1-2 Steckkarten verwendet werden, kann man das in eine TS Umgebung einbinden. Es gibt einige Thinclients die auch noch Steckkarten aufnehmen können =).
Hallo!
Nun gibt es in diversen Foren zur besagten Software Hinweise, dass die Umstellung auf Gigabit-LAN erhebliche Performance-Gewinne bringen soll...Nun frage ich mich, ob da was dran sein kann?
Wenn ihr nicht in der Lage seid, das Netzwerk als Flaschenhals auszumachen, aber dennoch weiterhin unsicher seid, dann verbinde doch mal einen Client mit dem Server über Gigabit und probier's aus, das sollte doch kein Problem sein (gekreuztes Kabel oder kleiner GBit-Switch für 20€).
Noch mal eine Frage zum TS:
Kann ich einen Server 2008 Std x64 (DC) mit entsprechenden TS CALs auf einem Server betreiben?
Sprich: Gilt die Problematik von DC und TS auf einem Server immer noch?
Der Witz ist halt, dass sich der DC an sich nur langweilt... alle PCs werden morgens einmal angeschaltet, Benutzer angemeldet und das Praxisprogramm gestartet. Abends wieder heruntergefahren... Zwischendrin passiert da nichts, sodass ich nicht glaube, dass die Performance da eine Rolle spielt...
Sollten da technische Gründe dagegen sprechen... könnte man ja einen ESXi Server aufsetzen und DC und TS so separieren...
Kann ich einen Server 2008 Std x64 (DC) mit entsprechenden TS CALs auf einem Server betreiben?
Sprich: Gilt die Problematik von DC und TS auf einem Server immer noch?
Der Witz ist halt, dass sich der DC an sich nur langweilt... alle PCs werden morgens einmal angeschaltet, Benutzer angemeldet und das Praxisprogramm gestartet. Abends wieder heruntergefahren... Zwischendrin passiert da nichts, sodass ich nicht glaube, dass die Performance da eine Rolle spielt...
Sollten da technische Gründe dagegen sprechen... könnte man ja einen ESXi Server aufsetzen und DC und TS so separieren...
