Temukan bottleneck untuk server desktop jarak jauh windows (Terminal server)


11

Saya memiliki Windows Server 2008 R2 (SP1) yang diinstal pada VMware Host saya untuk berfungsi sebagai server RDS. Terkadang pengguna jarak jauh saya dapat melihat lagging / delay pada server RDS. Adakah yang bisa memberi tahu saya dari pengalaman mereka apa praktik terbaik untuk menemukan hambatan untuk server ini?


1
Apa yang telah Anda lakukan untuk mencoba melacak latensi? Apakah klien ada di jaringan lokal? Komposisi peralatan jaringan? Apakah mereka semua ketinggalan pada saat yang sama? Sumber daya server; prosesor, RAM, disk? Monitor kinerja? Versi klien, ekstensi, RemoteFX?
Chris S

Jika Anda menjalankan TS, sebagai VM, lalu berapa banyak CPU virtual yang Anda tetapkan? Anda mungkin lebih baik dengan beberapa VM dengan jumlah CPU yang lebih kecil.
Zoredache

Terima kasih atas sarannya. Saya belum melakukan apa pun untuk melacak latensi. Akan mencoba mencari langkah demi langkah ...
Hemal

Jawaban:


16

Seperti yang disebutkan Chris S, ada beberapa hal yang dapat berkontribusi pada kinerja desktop jarak jauh yang buruk. Dari pengalaman saya, ini adalah penyebab utama, dalam urutan kemungkinan.

Bandwidth
Penyebab # 1 kinerja buruk dengan desktop jauh adalah kurangnya bandwidth. Bergantung pada apa yang sedang dilakukan, sebuah sesi dapat digunakan di mana saja dari beberapa Kbps hingga beberapa Mbps bandwidth. Tes saya sendiri telah menunjukkan bahwa menggulir melalui PDF akan menggunakan hingga 3 Mbps. Dengan berkurangnya bandwidth yang tersedia, kinerja juga dirasakan.

Pertama-tama Anda perlu menentukan kebutuhan bandwidth aplikasi Anda. Ini membutuhkan pengujian di lingkungan LAN yang terkontrol, kemudian mengukur penggunaan bandwidth saat Anda melakukan tugas normal. Saya pribadi sukses dengan NetLimiter di stasiun kerja pribadi saya. Anda juga dapat mendekati masalah dari sudut lain, dan menggunakan NetLimiter untuk memaksa kecepatan koneksi Anda turun ke nilai koneksi WAN Anda. Ini akan memberikan indikasi yang baik tentang apa yang dilihat pengguna jarak jauh Anda.

Setelah Anda tahu berapa banyak bandwidth yang diinginkan aplikasi Anda, Anda perlu menentukan apakah itu adalah faktor pembatas. Pertama, ukur bandwidth yang tersedia antara klien dan server. Alat yang sangat baik untuk ini adalah iperf. Saya akan berasumsi bahwa Anda memiliki bandwidth yang cukup tersedia selama tes terkontrol.

Selanjutnya, Anda akan ingin mengatur semacam pemantauan bandwidth untuk melihat apakah masalah yang dilaporkan pengguna berkorelasi dengan lonjakan lalu lintas atau yang tidak diinginkan lainnya. Preferensi saya adalah membuang lalu lintas dari sakelar atau router ke ntop, karena menyediakan laporan waktu nyata dan historis yang bermanfaat tentang penggunaan bandwidth.

Jika Anda mengalami masalah bandwidth, satu perubahan mudah adalah dengan mengubah pengaturan "Experience" pada koneksi desktop jarak jauh. Nonaktifkan gaya visual dan animasi, dan banyak operasi desktop akan tampak lebih cepat secara ajaib.

Latensi
Masalah umum lainnya dengan koneksi desktop jarak jauh adalah latensi. Perlu ada waktu pulang-pergi yang cukup cepat antara klien dan server, atau orang-orang akan dapat merasakan penundaan. Sebagai patokan, kebanyakan orang mulai memperhatikan masalah antara 50 dan 100 ms kali ping.

Untungnya, ini biasanya mudah didiagnosis. Anda dapat mengatur alat pemantauan seperti SmokePing atau PRTG Network Monitor untuk memberikan laporan tentang latensi antara server pemantauan Anda dan host sewenang-wenang lainnya. Anda bahkan dapat menggunakan ping -tperintah bawaan untuk sesi singkat. Biasanya Anda ingin mencari server pemantauan pada LAN yang sama dengan server desktop jarak jauh Anda, lalu atur pemantauan terhadap server dan klien Anda. Cobalah untuk menghubungkan laporan masalah dengan insiden waktu ping tinggi.

Jika Anda mengalami masalah dengan waktu ping tinggi, gunakan tracerouteuntuk mencari tahu di mana penundaan diperkenalkan. Jika Anda menentukan bahwa masalahnya ada di dalam jaringan Anda sendiri, pertimbangkan untuk memperkenalkan pemfilteran QoS untuk memprioritaskan lalu lintas waktu nyata seperti Remote Desktop.

Juga, waspadalah terhadap siapa pun yang menghubungkan melalui media nirkabel, apakah itu 802.11 (WiFi), atau lebih buruk lagi, koneksi satelit. Koneksi nirkabel rentan terhadap gangguan lingkungan yang dapat menyebabkan masalah latensi ekstrim dalam berbagai kondisi, dan untuk berbagai periode waktu. Dan menggunakan remote desktop melalui satelit selalu menyebalkan.

CPU atau memori lokal Dan akhirnya, mungkin server Anda terlalu terbebani. Monitor penggunaan CPU dan memori, terutama selama jam sibuk, untuk memastikan bahwa server mampu memenuhi permintaan secara tepat waktu.

Salah satu alat yang disebutkan di atas (PRTG) dapat diatur untuk memantau penggunaan CPU dan memori server dari waktu ke waktu, dan dapat menghasilkan grafik yang memudahkan untuk menghubungkan laporan masalah dengan masalah spesifik.

Kiat bonus: Jika pengguna Anda mengalami kesulitan mengetik, terutama yang berkaitan dengan tombol pengubah yang tidak berlaku dengan benar, coba ubah pengaturan keyboard Anda pada pintasan koneksi Remote Desktop sehingga Terapkan kombinasi tombol Windows diatur ke On the local computer.


Jawaban bagus. Saya mengelola tambak 20 server TS dan 2 penyebab paling umum masalah kinerja yang kami lihat adalah 2 yang Anda daftarkan pertama kali dalam jawaban Anda: bandwidth dan latensi. Menurut saya, 2 faktor ini memiliki dampak terbesar pada kinerja (atau kinerja yang dirasakan). Pengujian saya sendiri menunjukkan bahwa pengguna yang menjalankan beberapa aplikasi Office, IE, dan membuka file PDF mengkonsumsi rata-rata 100Kbps selama periode 8 jam. Itulah yang menjadi nomor perencanaan kami dalam hal alokasi bandwidth per pengguna dan itulah yang kami sarankan untuk dimiliki pelanggan agar memiliki sesi "berkinerja baik".
joeqwerty

Hai, terima kasih banyak atas jawaban terperinci yang bagus. Saya akan membahasnya dan akan mencoba mencari tahu .. Terima kasih banyak atas jawabannya. Terima kasih kepada Joeqwerty juga untuk komentar ..
Hemal

Saya mengelola pertanian kecil dan saya setuju. Kami juga menggunakan PRTG untuk melihat apakah data historis cocok dengan masalah yang dilaporkan. Masalah nomor dua kami adalah bandwitch (masalah lokal / ISP) dan CPU (program buruk pada server hitung inti rendah). Cara terbaik untuk melihat dengan cepat apakah bandwidth adalah untuk bertanya kepada pengguna apakah input teks tampaknya lambat.
Gomibushi

Anda menyebutkan banyak alat yang hebat, tetapi berapa banyak sesi kebutuhan bandwidth yang dapat dikumpulkan melalui WMI? atau penghitung kinerja yang lebih baik? Saya baru mengenal TS, tetapi ditugaskan untuk memunculkan berbagai statistik dalam satu sesi. Terima kasih sebelumnya atas waktu Anda.
codeputer

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.