europc
Goto Top

Win2008R2 Terminal clients mit langsamer Graphik

Hallo liebe Experten,

ich verwalte ein kleines Unternehmensnetzwerk bestehend u.a. aus einem Win2008R2 Server, über den fünf Clients via VPN angeschlossen sind.
Auf diesen (meist Core I3 Haswell mit 4 GB Ram und Win7 Pro 32 Bit) läuft jeweils die selbe Anwendung (ein Kassensystem) via RemoteDesktop- Verbindung.
Der Server ist ein HP Server mit Xeon X3460, 8 GB Ram und einer Samsung 850 Pro SSD.

Einen Überblick über die Infrastruktur findet ihr im Anhang.
Dabei arbeiten nur die Clients auf dem Win- Server, der dann seinerseits auf dem Linux- Server arbeitet. Die Rechner 1-5 arbeiten ausschließlich auf dem Linux- Server.
Als Datenbank- Server (SUSE) werkelt ein Fujitsu PRIMERGY TX100 S3 Server mit Intel® Xeon®-Prozessor E3-1220, 8 GB RAM und 500 GB SATA- HDD.

Nun ist mein Problem, dass der Bildaufbau auf den Clients im angeschlossenen Mandanten sehr langsam ist. Allerdings sehe ich auf dem Win- Server keine/ kaum Last (i.d.R. 0-1%).
Das Programm, ein Kassen- Programm, muß allerdings oft eine komplett andere Maske anzeigen.

Prüfe ich die Geschwindigkeit des VPN per NET-IO kommt es zu folgendem Ergebnis:

Prüfung im LAN:
NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel

TCP connection established.
Packet size 1k bytes: 77.15 MByte/s Tx, 96.27 MByte/s Rx.
Packet size 2k bytes: 101.31 MByte/s Tx, 108.67 MByte/s Rx.
Packet size 4k bytes: 110.72 MByte/s Tx, 112.74 MByte/s Rx.
Packet size 8k bytes: 109.77 MByte/s Tx, 112.76 MByte/s Rx.
Packet size 16k bytes: 110.74 MByte/s Tx, 112.31 MByte/s Rx.
Packet size 32k bytes: 111.23 MByte/s Tx, 113.02 MByte/s Rx.
Done.


NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel

UDP connection established.
Packet size 1k bytes: 100.10 MByte/s (0%) Tx, 84.89 MByte/s (0%) Rx.
Packet size 2k bytes: 104.49 MByte/s (5%) Tx, 17.18 MByte/s (1%) Rx.
Packet size 4k bytes: 107.96 MByte/s (1%) Tx, 25.62 MByte/s (0%) Rx.
Packet size 8k bytes: 60.08 MByte/s (2%) Tx, 37.64 MByte/s (0%) Rx.
Packet size 16k bytes: 78.36 MByte/s (3%) Tx, 57.93 MByte/s (0%) Rx.
Packet size 32k bytes: 80.26 MByte/s (3%) Tx, 68.77 MByte/s (0%) Rx.
Done.

und über das VPN

NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel

TCP connection established.
Packet size 1k bytes: 551.05 KByte/s Tx, 483.88 KByte/s Rx.
Packet size 2k bytes: 565.39 KByte/s Tx, 531.09 KByte/s Rx.
Packet size 4k bytes: 569.24 KByte/s Tx, 489.20 KByte/s Rx.
Packet size 8k bytes: 568.59 KByte/s Tx, 533.77 KByte/s Rx.
Packet size 16k bytes: 569.55 KByte/s Tx, 535.42 KByte/s Rx.
Packet size 32k bytes: 575.61 KByte/s Tx, 533.23 KByte/s Rx.
Done.

NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel

UDP connection established.
Packet size 1k bytes: 552.67 KByte/s (99%) Tx, 476.39 KByte/s (98%) Rx.
Packet size 2k bytes: 36.67 KByte/s (99%) Tx, 365.94 KByte/s (92%) Rx.
Packet size 4k bytes: 14.00 KByte/s (99%) Tx, 327.48 KByte/s (96%) Rx.
Packet size 8k bytes: 10.67 KByte/s (99%) Tx, 63.76 KByte/s (99%) Rx.
Packet size 16k bytes: 13.34 KByte/s (99%) Tx, 56.25 KByte/s (99%) Rx.
Packet size 32k bytes: 10.67 KByte/s (99%) Tx, 15.17 KByte/s (99%) Rx.
Done.

In einem anderen Thread von euch habe ich schon gelesen, man solle die Farbtiefe herunterschrauben und auch die Verbindung beim Client auf "Modem" setzen.
Leider scheint auch das nichts zu bringen (oder ich erhoffe mir zu viel bei dieser alten Server- Hardware).
Wenn aber die Server- Hardware wirklich überfordert wäre, dann müssten doch CPU- Auslastung etc. am Anschlag liegen, oder nicht?

Danke und schönes Wochenende,
EuroPC
6222ff-1470298396

Content-Key: 336510

Url: https://administrator.de/contentid/336510

Ausgedruckt am: 19.03.2024 um 02:03 Uhr

Mitglied: XPFanUwe
XPFanUwe 29.04.2017 um 23:15:11 Uhr
Goto Top
Hm, 8 GB RAM auf Server 2008R2 ist a sehr bissel wenig. Ich habe in einem Testsystem 32 drinnen.
Mitglied: EuroPC
EuroPC 30.04.2017 aktualisiert um 08:56:49 Uhr
Goto Top
Hallo XPFanUwe,

Laut unserem IT- Dienstleister sind sogar 4 GB ausreichend. Ich habe dann 4 GB zusätzlich verbaut.
Der RAM ist idR zu 2-3 GB belegt. Von daher sollten 8 GB locker reichen. Außerdem müssten dann Taskmanager und Performancemonitor doch entsprechend darauf hinweisen, oder?
Mitglied: em-pie
em-pie 30.04.2017 aktualisiert um 10:38:47 Uhr
Goto Top
Moin,

ich würde hier mal auf den VPN-Tunnel tippen...

Kannst du einsehen, wie ausgelastet die (beiden?) VDSL-Leitung in beiden Richtungen sind?
Also DSL am Hauptstandort: TX und RX
Also DSL am Nebenstandort: TX und RX

Wenn nämlich eine der beiden WAN-Seiten voll ausgelastet ist (weil 3 MAs am Hauptstandort HD-Videos bei Youtube schauen), bringt auch das Tuning am RDP selbst nichts.

Prüfe auch mal, ob die MTU-Size auf beiden Seiten stimmt.
Gerade wenn VPN im Einsatz ist, muss man hier vom klassischen 1492 auf meist 1456 o.Ä. reduzieren; und zwar auf beiden Seiten:
https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on- ...

Wer baut den VPN auf?
Die Elmegs? Wenn Ja, sind die Fritzboxen nur als Modem eingerichtet oder als voll-aktive Router?

Ich denke nämlich nicht, dass es zunächst die Clients/ der Server selbst ist.
Wäre es ein Serverproblem, müsste das mit hoher Wahrscheinlichkeit sich auch auf den Clients beim Hauptmandanten auswirken....

Gruß
em-pie
Mitglied: EuroPC
EuroPC 30.04.2017 aktualisiert um 12:02:28 Uhr
Goto Top
Hi em-pie,

das VPN wird von den Elmegs aufgebaut. Diese hängen als Exposed host hinter der Fritze. Zudem stellen sie den DynDNS- Zugang bereit (über selfhost).

Das mit der mtu prüfe ich mal. Die müsste dann in den Elmegs geändert werden?


Hier kommt das Ergebnis ping via VPN:
Hauptmandant --> angeschlossener Mandant
C:\>ping 10.52.51.90 -f -l 1390

Ping wird ausgeführt für 10.52.51.90 mit 1390 Bytes Daten:
Antwort von 10.52.51.90: Bytes=1390 Zeit=44ms TTL=62
Antwort von 10.52.51.90: Bytes=1390 Zeit=44ms TTL=62
Antwort von 10.52.51.90: Bytes=1390 Zeit=43ms TTL=62
Antwort von 10.52.51.90: Bytes=1390 Zeit=44ms TTL=62

Ping-Statistik für 10.52.51.90:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 43ms, Maximum = 44ms, Mittelwert = 43ms

C:\>


und umgekehrt:
C:\>ping 10.52.52.1 -f -l 1390

Ping wird ausgeführt für 10.52.52.1 mit 1390 Bytes Daten:
Antwort von 10.52.52.1: Bytes=1390 Zeit=44ms TTL=62
Antwort von 10.52.52.1: Bytes=1390 Zeit=44ms TTL=62
Antwort von 10.52.52.1: Bytes=1390 Zeit=44ms TTL=62
Antwort von 10.52.52.1: Bytes=1390 Zeit=44ms TTL=62

Ping-Statistik für 10.52.52.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 44ms, Maximum = 44ms, Mittelwert = 44ms


Die Clients im Hauptmandanten sind werden direkt vom Linux- Server bedient. Nur der angeschlossene Mandant läuft via Terminal- Server.
Vorstellbar wäre zwar, dass eigentlich dieser überlastet ist, auch wenn er der neuere Server ist. Ich kann dort aber leider nichts einsehen und müsste indirekt messen.

Danke und schönen Sonntag,
EuroPC
Mitglied: EuroPC
EuroPC 11.05.2017 um 08:26:26 Uhr
Goto Top
Hallo,

leider kann ich auf den Elmeg nicht zugreifen, da mir die Berechtigungen fehlen. Die hat nur unser Dienstleister.
Ich habe mal eine Graphik des Performance Monitors beigelegt. Mit den csv- Dateien kann ich nun gar nichts anfangen, reiche die aber bei Bedarf nach. Die Counter sind die die auch im Terminal Server Sizig guide (http://sp.ts.fujitsu.com/dmsp/Publications/public/Terminal_Server_Sizin ..) empfohlen werden.


Gruß,
EuroPC
100517