Tìm hiểu nút cổ chai cho máy chủ máy tính từ xa windows (Máy chủ đầu cuối)


11

Tôi đã cài đặt máy chủ Windows 2008 R2 (SP1) trên VMware Host để hoạt động như máy chủ RDS. Đôi khi người dùng từ xa của tôi có thể thấy độ trễ / độ trễ trên máy chủ RDS. Bất cứ ai có thể cho tôi biết từ kinh nghiệm của họ những thực tiễn tốt nhất để tìm ra nút cổ chai cho máy chủ này là gì?


1
Bạn đã làm gì để cố gắng theo dõi độ trễ? Là các khách hàng trên một mạng cục bộ? Thành phần thiết bị mạng? Có phải tất cả đều tụt hậu cùng một lúc? Tài nguyên máy chủ; bộ xử lý, RAM, đĩa? Giám sát hiệu suất? Phiên bản máy khách, tiện ích mở rộng, RemoteFX?
Chris S

Nếu bạn đang chạy TS, với tư cách là VM, thì bạn đã gán bao nhiêu CPU ảo? Bạn có thể tốt hơn với nhiều máy ảo có số lượng CPU ít hơn.
Zoredache

Cảm ơn về những đề nghị. Tôi chưa làm gì để theo dõi độ trễ. Sẽ cố gắng tìm ra từng bước một ...
Hemal

Câu trả lời:


16

Như Chris S đã đề cập, có một số điều có thể đóng góp cho hiệu suất máy tính từ xa kém. Từ kinh nghiệm của tôi, đây là những nguyên nhân chính, theo thứ tự khả năng.

Băng thông
Nguyên nhân số 1 của hiệu suất kém với máy tính để bàn từ xa là thiếu băng thông. Tùy thuộc vào chính xác những gì đang được thực hiện, một phiên có thể sử dụng bất cứ nơi nào từ một vài Kb / giây đến một vài Mbps băng thông. Các thử nghiệm của riêng tôi đã chỉ ra rằng việc cuộn qua PDF sẽ sử dụng tới 3 Mbps. Khi băng thông có sẵn giảm, hiệu suất cảm nhận cũng vậy.

Trước tiên bạn cần xác định nhu cầu băng thông của ứng dụng của bạn. Điều này yêu cầu kiểm tra trong môi trường LAN được kiểm soát, sau đó đo mức sử dụng băng thông khi bạn thực hiện các tác vụ bình thường. Cá nhân tôi đã thành công với NetLimiter trên máy trạm cá nhân của mình. Bạn cũng có thể tiếp cận vấn đề từ một góc độ khác và sử dụng NetLimiter để giảm tốc độ kết nối của bạn xuống bất cứ điều gì kết nối mạng của bạn được đánh giá. Điều này sẽ cung cấp một dấu hiệu tốt về những gì người dùng từ xa của bạn đang nhìn thấy.

Một khi bạn biết ứng dụng của bạn muốn có bao nhiêu băng thông, bạn cần xác định xem đó có phải là yếu tố giới hạn hay không. Đầu tiên, đo băng thông có sẵn giữa máy khách và máy chủ. Một công cụ tuyệt vời cho việc này là iperf. Tôi sẽ cho rằng bạn có đủ băng thông có sẵn trong quá trình kiểm tra.

Tiếp theo, bạn sẽ muốn thiết lập một số loại giám sát băng thông để xem liệu các vấn đề do người dùng báo cáo có tương quan với các đột biến trong lưu lượng truy cập hoặc các điều không mong muốn khác hay không. Sở thích của tôi là chuyển lưu lượng truy cập từ một bộ chuyển mạch hoặc bộ định tuyến vào ntop, vì nó cung cấp các báo cáo lịch sử và thời gian thực hữu ích về việc sử dụng băng thông.

Nếu bạn gặp phải vấn đề về băng thông, một thay đổi dễ dàng là thay đổi cài đặt "Trải nghiệm" trên kết nối máy tính để bàn từ xa. Vô hiệu hóa các kiểu và hình ảnh động, và nhiều thao tác trên máy tính để bàn sẽ có vẻ nhanh hơn.

Độ trễ
Một vấn đề phổ biến khác với các kết nối máy tính từ xa là độ trễ. Cần có thời gian khứ hồi hợp lý nhanh chóng giữa máy khách và máy chủ, hoặc mọi người sẽ có thể nhận thấy sự chậm trễ. Theo nguyên tắc thông thường, hầu hết mọi người bắt đầu nhận thấy các vấn đề trong khoảng thời gian ping từ 50 đến 100 ms.

May mắn thay, điều này thường dễ chẩn đoán. Bạn có thể thiết lập các công cụ giám sát như SmokePing hoặc PRTG Network Monitor để cung cấp các báo cáo về độ trễ giữa máy chủ giám sát của bạn và bất kỳ máy chủ tùy ý nào khác. Bạn thậm chí có thể chỉ sử dụng ping -tlệnh tích hợp cho các phiên ngắn. Thông thường bạn muốn định vị máy chủ giám sát trên cùng mạng LAN với máy chủ để bàn từ xa, sau đó thiết lập giám sát đối với cả máy chủ và máy khách của bạn. Cố gắng tương quan các báo cáo vấn đề với sự cố thời gian ping cao.

Nếu bạn gặp vấn đề với thời gian ping cao, hãy sử dụng tracerouteđể tìm hiểu nơi trì hoãn được đưa ra. Nếu bạn xác định rằng sự cố nằm trong mạng riêng của mình, hãy xem xét giới thiệu bộ lọc QoS để ưu tiên lưu lượng thời gian thực như Remote Desktop.

Ngoài ra, hãy cảnh giác với bất kỳ ai đang kết nối qua phương tiện không dây, cho dù đó là 802.11 (WiFi) hay tệ hơn là kết nối vệ tinh. Kết nối không dây dễ bị can thiệp môi trường có thể gây ra vấn đề độ trễ cực kỳ trong các điều kiện khác nhau và trong các khoảng thời gian khác nhau. Và sử dụng máy tính để bàn từ xa thông qua một vệ tinh luôn hút.

CPU hoặc bộ nhớ cục bộ Và cuối cùng, có thể máy chủ của bạn chỉ bị quá tải. Giám sát việc sử dụng CPU và bộ nhớ, đặc biệt là trong giờ cao điểm, để đảm bảo rằng máy chủ có khả năng đáp ứng các yêu cầu một cách kịp thời.

Một trong những công cụ được đề cập ở trên (PRTG) có thể được thiết lập để giám sát việc sử dụng CPU và bộ nhớ của máy chủ theo thời gian và có thể tạo ra các biểu đồ giúp dễ dàng tương quan các báo cáo sự cố với các lỗi cụ thể.

Mẹo thưởng: Nếu người dùng của bạn gặp khó khăn khi nhập, đặc biệt là liên quan đến các phím bổ trợ không được áp dụng đúng cách, hãy thử thay đổi cài đặt bàn phím của bạn trên phím tắt kết nối Remote Desktop để áp dụng tổ hợp phím Windows On the local computer.


Câu trả lời tốt đẹp. Tôi quản lý một trang trại gồm 20 máy chủ TS và 2 nguyên nhân phổ biến nhất gây ra vấn đề về hiệu suất mà chúng tôi thấy là 2 nguyên nhân bạn liệt kê đầu tiên trong câu trả lời của bạn: băng thông và độ trễ. Hai yếu tố này có tác động lớn nhất đến hiệu suất (hoặc hiệu suất cảm nhận) theo ý kiến ​​của tôi. Thử nghiệm của riêng tôi cho thấy rằng một người dùng chạy một số ứng dụng Office, IE và mở tệp PDF đã tiêu thụ trung bình 100Kb / giây trong khoảng thời gian 8 giờ. Đó là số kế hoạch của chúng tôi là về phân bổ băng thông cho mỗi người dùng và đó là những gì chúng tôi khuyên khách hàng của mình có để có các phiên "hoạt động tốt".
joeqwerty

Xin chào Nic, Cảm ơn bạn rất nhiều vì câu trả lời chi tiết tốt đẹp. Tôi sẽ đi qua nó và sẽ cố gắng tìm ra nó .. Cảm ơn rất nhiều cho câu trả lời. Cảm ơn Joeqwerty cũng đã cho ý kiến ​​..
Hemal

Tôi quản lý một trang trại nhỏ và tôi đồng ý. Chúng tôi cũng sử dụng PRTG để xem liệu dữ liệu lịch sử có khớp với các vấn đề được báo cáo hay không. Vấn đề số hai của chúng tôi là bandwitch (vấn đề cục bộ / ISP) và CPU (chương trình xấu trên máy chủ số lượng lõi thấp). Cách tốt nhất để nhanh chóng xem liệu băng thông có phải là hỏi người dùng xem liệu nhập văn bản có bị trễ không.
Gomibushi

Bạn đã đề cập đến rất nhiều công cụ tuyệt vời, nhưng có thể thu thập được bao nhiêu yêu cầu băng thông qua WMI? hoặc thậm chí tốt hơn quầy hiệu suất? Tôi mới làm quen với TS, nhưng được giao nhiệm vụ hiển thị các số liệu thống kê khác nhau trên một phiên. Thks trước cho thời gian của bạn.
mật mã

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.