Mengapa RDP terasa berat padahal koneksinya cepat? — Selidiki input, rendering, dan komunikasi secara terpisah

Uji kecepatan menunjukkan ratusan Mbps, tetapi di Desktop Jauh karakter muncul sedikit terlambat. Saat halaman yang banyak fotonya digulir, layar tersendat. Hanya ketika tombol pencarian di aplikasi bisnis ditekan, layar berhenti beberapa detik. Dari mana sebaiknya keadaan “koneksinya cepat tetapi RDP terasa berat” seperti ini diselidiki?

Responsivitas operasi di RDP tidak ditentukan oleh kecepatan transfer koneksi saja. Meskipun hasil uji kecepatan tinggi, penantian bisa terjadi di salah satu titik: perjalanan pulang-pergi jaringan, penantian input di aplikasi pada komputer tujuan, encoding layar, atau decoding dan tampilan di perangkat lokal. Pertama, pisahkan “operasi apa yang lambat”, lalu bandingkan operasi yang sama dengan mengubah satu kondisi saja setiap kali. Persempit sasaran penyelidikan melalui perbandingan dan pengukuran, lalu pilih pengaturan UDP atau GPU sesuai hasilnya. Lihat: Rentang pengukuran kualitas koneksi, Faktor kinerja session host.

Namun, pada tahap sasaran penyelidikan sudah dipersempit, akar penyebabnya belum dipastikan. Meskipun keadaan membaik setelah resolusi diturunkan, yang berubah bukan hanya komunikasi jaringan tetapi juga pemrosesan layar di kedua ujung, sehingga tidak disimpulkan bahwa “penyebabnya adalah koneksi”. Catat hasilnya dengan memisahkan rentang yang diukur dan rentang yang tidak diukur.

Artikel ini memilah input, pengguliran, dan respons aplikasi setelah koneksi terbentuk. Meskipun gejalanya mirip, penyebabnya belum tentu satu. Kasus “layar login lama sekali muncul” atau “berhenti hanya saat autentikasi” diperlakukan sebagai masalah lain yang diselidiki dari catatan pembentukan koneksi dan autentikasi.

Sasaran utamanya adalah pengguna dan administrator yang terhubung dari “Koneksi Desktop Jauh” (mstsc) di Windows ke Windows 11 atau Windows Server. Contoh perintah ditujukan untuk Windows PowerShell 5.1. Artikel ini mengasumsikan bahwa operasi yang sama dapat direproduksi di sesi yang sudah terhubung.

Koneksi langsung, VPN, RD Gateway, dan Azure Virtual Desktop berbeda dalam hal jalur, informasi diagnostik yang tersedia, dan sasaran penerapan pengaturan. Contoh pemeriksaan TCP 3389 hanya berlaku untuk koneksi langsung yang diizinkan ke host RDP yang memakai port standar. Fitur diagnostik dan pengaturan GPU dari dokumentasi untuk Azure Virtual Desktop tidak diterapkan begitu saja ke PC kantor biasa.

Pada perangkat milik perusahaan, lakukan penyelidikan dalam batas yang diizinkan administrator. Di host bersama, identifikasi sesi Anda sendiri dan proses sasaran; jika catatan pengguna lain diperlukan, mintalah kepada administrator. Ketersediaan, nama tampilan, dan hak akses yang diperlukan untuk performance counter diperiksa di setiap lingkungan.

Metode pemeriksaan yang ditunjukkan di sini didasarkan pada dokumentasi resmi. Ini bukan laporan pengukuran nyata tentang mereproduksi dan mengatasi gangguan pada perangkat tertentu. Contoh angka disajikan dengan dibedakan secara jelas sebagai asumsi untuk penjelasan.

Mekanismenya dapat dibaca berurutan mulai dari bagian berikut, “Kecepatan transfer dan waktu pulang-pergi”. Jika ingin mulai menyelidiki dari gejala, lanjutkan ke “Perbandingan pertama menurut gejala”. Langkah-langkah operasinya ada di “Membandingkan kondisi satu per satu” dan “Mengukur titik penantian”.

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 7, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

Kecepatan transfer dan waktu pulang-pergi

RDP (Remote Desktop Protocol) adalah protokol untuk bertukar input, informasi layar, dan sebagainya antara perangkat lokal dan komputer tujuan. Protokol ini tidak hanya menangani layar dan input, tetapi juga informasi seperti pengalihan perangkat dan pencetakan. Lihat: Informasi yang ditransfer RDP.

Kecepatan transfer koneksi menyatakan berapa banyak data yang dapat diangkut dalam satu detik. Angka “500Mbps” pada uji kecepatan adalah angka tentang jumlah ini. Angka itu tidak menunjukkan waktu dari melakukan operasi sampai balasannya tiba. Lihat: Kebutuhan bandwidth RDP.

flowchart TB
    accTitle: Apa yang dinyatakan angka uji kecepatan
    accDescr: Angka 500Mbps pada uji kecepatan menyatakan jumlah data yang dapat diangkut dalam satu detik, dan merupakan angka yang berbeda dari waktu sejak operasi dilakukan sampai balasan tiba.
    A["Uji kecepatan: 500Mbps"] --> B["Data yang terangkut per detik"]
    B -.->|"Angka yang berbeda"| C["Waktu sampai balasan tiba"]

Gambar 1: Angka uji kecepatan menyatakan jumlah yang dapat diangkut, bukan waktu sampai balasan tiba.

Waktu pulang-pergi (RTT) adalah waktu yang dibutuhkan komunikasi untuk sampai ke tujuan dan kembali. Menaikkan kecepatan transfer dan memperpendek waktu pulang-pergi berbeda seperti halnya menambah lajur jalan dan memperpendek jarak ke tempat tujuan. Meskipun kemampuan mengangkut file dalam jumlah besar bertambah, jika waktu pulang-pergi tetap sama, penantian balasan atas operasi tetap ada. Lihat: RTT dan keterlambatan tampilan layar.

flowchart TB
    accTitle: Mengibaratkan kecepatan transfer dan waktu pulang-pergi dengan jalan
    accDescr: Diagram yang mengibaratkan menaikkan kecepatan transfer dengan menambah lajur jalan, dan memperpendek waktu pulang-pergi dengan memperpendek jarak ke tempat tujuan.
    A["Naikkan kecepatan transfer"] -->|"Ibarat jalan"| B["Tambah lajur"]
    B ~~~ C["Perpendek waktu pulang-pergi"]
    C -->|"Ibarat jalan"| D["Perpendek jarak"]

Gambar 2: Menambah lajur tidak memperpendek jarak ke tempat tujuan.

Sampai hasil satu karakter kembali

Bayangkan situasi mengetik satu karakter ke Notepad jarak jauh. Notepad berjalan di komputer tujuan. Untuk penjelasan, jika diasumsikan operasi butuh 50 milidetik untuk sampai dan informasi layar hasilnya butuh 50 milidetik untuk kembali, waktu yang dipakai untuk komunikasi totalnya 100 milidetik, yaitu 0,1 detik. Waktu pemrosesan di kedua ujung dikecualikan dari contoh ini.

flowchart TB
    accTitle: Contoh waktu komunikasi sampai hasil satu karakter kembali
    accDescr: Contoh untuk penjelasan yang mengasumsikan perjalanan pergi dan pulang masing-masing 50 milidetik. Waktu pemrosesan di kedua ujung tidak dihitung, dan diagram ini juga tidak menyatakan jumlah paket per tombol.
    A["Ketik satu karakter di lokal"] -->|"Pergi: 50 milidetik"| B["Tujuan menerima input"]
    B --> C["Kirim layar yang memuat input"]
    C -->|"Pulang: 50 milidetik"| D["Hasil tiba di lokal"]

Gambar 3: Seandainya pergi 50 milidetik dan pulang 50 milidetik, komunikasinya saja sudah memakan 0,1 detik. Ini bukan nilai hasil pengukuran.

Meskipun jumlah yang dapat diangkut koneksi bertambah, 0,1 detik ini tetap ada selama waktu pulang-pergi tidak berubah. Gambar 3 adalah diagram konseptual untuk memahami prosesnya. Artinya bukan setiap tombol mengirim paket tersendiri dalam satu perjalanan pulang-pergi. Jalur ke server uji kecepatan dan ke tujuan RDP juga berbeda, sehingga VPN, gateway, arah upstream di sisi tujuan, dan kemacetan di tengah jalur ikut diperhitungkan. Lihat: Cara memahami RTT, Kinerja jaringan dan host.

Proses membuat dan mengirim layar

Keterlambatan respons operasi yang dimaksud di sini adalah penantian sejak operasi dilakukan di perangkat lokal sampai hasilnya terlihat. Yang berperan bukan hanya RTT, tetapi juga pemrosesan aplikasi serta proses membuat dan mengirim layar. Keterlambatan ini juga dibedakan dari keterlambatan pada rentang transfer layar saja. Lihat: Rentang pengukuran dari pengambilan layar sampai tampilan.

Ketika input dari perangkat lokal tiba di komputer tujuan, aplikasi di komputer tujuan memproses input dan memperbarui layar, informasi layar hasil encoding diangkut melalui koneksi, lalu perangkat lokal melakukan decoding dan menampilkannya. Sebelum dan sesudah komunikasi pun ada pekerjaan yang ditangani oleh PC yang berbeda. Lihat: Pemrosesan dari pengambilan layar sampai tampilan.

flowchart TB
    accTitle: Ada pemrosesan layar sebelum dan sesudah koneksi
    accDescr: Alur sejak input lokal tiba di komputer tujuan, aplikasi di komputer tujuan memprosesnya, layar dibuat dan dikompresi, informasi layar diangkut melalui koneksi, lalu dikembalikan ke bentuk yang dapat ditampilkan dan ditampilkan di perangkat lokal.
    I["Lokal: masukkan operasi"] --> J["Koneksi: angkut input"]
    J --> K["Tujuan: aplikasi memproses"]
    K --> A["Tujuan: buat dan kompresi layar"]
    A --> B["Koneksi: angkut info layar"]
    B --> C["Lokal: kembalikan ke bentuk tampil"]
    C --> D["Tampil di layar lokal"]

Gambar 4: Pemrosesan dan kompresi di komputer tujuan, pengangkutan melalui koneksi, dan pengembalian ke bentuk tampilan di perangkat lokal adalah pekerjaan yang dilakukan di tempat yang berbeda.

Encoding dalam artikel ini adalah proses di komputer tujuan untuk mengubah dan mengompresi layar ke bentuk yang mudah dikirim. Terlepas dari transfer melalui koneksi, proses ini memakan waktu pemrosesan di komputer tujuan. Lihat: Waktu encoding di komputer tujuan.

Decoding dalam artikel ini adalah proses mengembalikan informasi layar yang diterima ke bentuk yang dapat ditampilkan di perangkat lokal. Ini dibedakan dari dekripsi dalam arti membuka enkripsi. Lihat: Waktu decoding dan tampilan di perangkat lokal.

Jika kompresi di komputer tujuan memakan waktu, pengiriman menunggu persiapan selesai meskipun koneksi sedang lowong. Meskipun informasinya sudah tiba, pembaruan akan terlambat jika decoding atau tampilan di perangkat lokal tidak mampu mengimbangi. Belum tentu benar bahwa “PC kantor berperforma tinggi, jadi perangkat lokal apa saja boleh”. Kelonggaran koneksi dan kelonggaran pemrosesan di kedua ujungnya adalah hal yang berbeda. Lihat: Performance counter untuk pemrosesan layar.

flowchart TB
    accTitle: Keterlambatan saat pemrosesan di kedua ujung tidak mengimbangi
    accDescr: Menunjukkan bahwa jika kompresi di komputer tujuan memakan waktu, pengiriman menunggu persiapan meskipun koneksi lowong, dan jika decoding atau tampilan di perangkat lokal tidak mengimbangi, pembaruan terlambat meskipun informasinya sudah tiba.
    A["Kompresi di tujuan lama"] --> B["Kirim tertunda meski koneksi lowong"]
    B ~~~ C["Decoding lokal tak mengimbangi"]
    C --> D["Sudah tiba tapi pembaruan terlambat"]

Gambar 5: Meskipun koneksi longgar, pembaruan layar terlambat jika pemrosesan di kedua ujung tidak mampu mengimbangi.

Perbedaan mengetik dan menggulir

Saat satu karakter ditambahkan di Notepad, yang berubah hanya sebagian kecil layar. Saat halaman yang banyak fotonya digulir, tampilan di area yang luas berubah terus-menerus. RDP menekan volume komunikasi dengan mentransfer bagian yang berubah serta dengan kompresi dan cache yang sesuai dengan isinya. RDP tidak mengirim seluruh layar tanpa kompresi setiap kali. Beban kerjanya berubah menurut isi layar dan frekuensi pembaruan. Lihat: Hubungan isi layar dan bandwidth.

flowchart TB
    accTitle: Beban kerja layar yang berubah antara mengetik dan menggulir
    accDescr: Perubahan kecil berupa teks dan pembaruan beruntun pada area yang luas berbeda sifat pekerjaannya dalam membuat dan mengirim layar.
    A{"Perubahan layar"} -->|"Tambah satu karakter"| B["Area kecil"]
    A -->|"Gulir"| D["Area luas beruntun"]
    B --> E["Kompresi dan transfer sesuai perubahan"]
    D --> E

Gambar 6: Pada koneksi yang sama pun, beban kerja berbeda antara menambah satu karakter dan area luas yang terus bergerak.

Dokumen yang diam mungkin ringan, tetapi selama pengguliran transfer layar bisa kehilangan kelonggarannya. Jika resolusi sisi jarak jauh atau jumlah monitor ditambah, layar yang harus diproses juga menjadi lebih besar. Perbandingan dengan menurunkan resolusi adalah eksperimen untuk melihat apakah gerakan kembali lancar ketika pekerjaan membuat dan mengirim layar dikurangi. Ini bukan perhitungan yang menentukan volume komunikasi hanya dari jumlah piksel. Lihat: Pengaruh resolusi, pembaruan layar, dan kompresi.

Aplikasi yang sedang menunggu

Jika hanya pencarian di aplikasi bisnis yang berhenti beberapa detik, sementara Notepad di sesi yang sama bisa diketik dengan normal, periksa apa yang ditunggu oleh aplikasi itu. Aplikasi di komputer tujuan bisa saja meminta pencarian ke DB lain atau membaca file dari folder bersama, lalu menunggu balasannya. Ini adalah jalur yang berbeda dari komunikasi RDP yang menghubungkan perangkat lokal dan komputer tujuan. Lihat: Komunikasi dari komputer tujuan ke backend.

flowchart TB
    accTitle: Di balik RDP pun ada mitra komunikasi
    accDescr: Menunjukkan kasus ketika aplikasi di komputer tujuan menunggu balasan dari server bisnis, terpisah dari komunikasi yang menghubungkan perangkat lokal dan komputer tujuan.
    A["Perangkat lokal"] -->|"RDP"| B["Aplikasi bisnis di tujuan"]
    B -->|"Pencarian, permintaan file"| C["DB, folder bersama"]
    C -->|"Balasan yang ditunggu"| B

Gambar 7: Aplikasi bisnis di balik RDP bisa menunggu balasan dari server lain lagi.

Jika pemrosesan yang menangani layar dan input memikul pekerjaan yang panjang, input berikutnya dan pembaruan layar akan terlambat. Misalnya di WPF, responsivitas menurun jika thread UI ditempati dalam waktu lama. Penggunaan CPU keseluruhan yang rendah saja tidak dapat menyangkal adanya penantian pada thread UI tertentu. Lihat: Dispatcher dan thread UI.

flowchart TB
    accTitle: Pemrosesan yang menangani layar dan input tersumbat
    accDescr: Menunjukkan bahwa jika pemrosesan yang menangani layar dan input memikul pekerjaan panjang, input berikutnya dan pembaruan layar terlambat, dan penggunaan CPU keseluruhan yang rendah saja tidak dapat menyangkal penantian itu.
    A["Pemrosesan layar dan input"] --> B["Memikul pekerjaan panjang"]
    B --> C["Input dan pembaruan berikutnya terlambat"]
    C -.- D["CPU total rendah pun tak menyangkalnya"]

Gambar 8: Penantian thread UI tidak dapat disangkal hanya dari penggunaan CPU keseluruhan.

Perbandingan pertama menurut gejala

Jumlah yang dapat diangkut, waktu menunggu balasan, dan waktu membuat serta menampilkan layar adalah hal yang berbeda. Dengan menjaga pembedaan ini, “RDP terasa berat” tidak dituntaskan dengan satu penyebab saja, dan penyelidikan bisa dimulai dari operasi yang sedang lambat.

flowchart TB
    accTitle: Pisahkan ketiganya sebelum menyelidiki
    accDescr: Menunjukkan bahwa “RDP terasa berat” tidak dituntaskan dengan satu penyebab, melainkan jumlah yang dapat diangkut, waktu menunggu balasan, dan waktu membuat serta menampilkan layar dipisahkan, lalu penyelidikan dimulai dari operasi yang sedang lambat.
    A["“RDP terasa berat”"] --> S
    subgraph S["Lihat secara terpisah"]
    direction TB
    B["Jumlah yang terangkut"] ~~~ C["Waktu menunggu balasan"]
    C ~~~ D["Waktu membuat dan menampilkan layar"]
    end
    S --> E["Selidiki dari operasi yang lambat"]

Gambar 9: Dengan memisahkan jumlah yang dapat diangkut, waktu menunggu balasan, dan waktu membuat serta menampilkan layar, penyelidikan bisa dimulai dari operasi yang sedang lambat.

Tujuan pemilahan adalah membatasi tempat yang diselidiki untuk mencari sumber kelambatan. Mengubah pengaturan sekaligus lalu kebetulan menjadi cepat bukanlah tujuannya. Dengan memanfaatkan perbedaan seperti “Notepad berjalan tetapi hanya pencarian yang berhenti” atau “mengetik normal tetapi hanya pengguliran yang berat”, titik awal penyelidikan dapat dipilih bahkan sebelum pengaturan komunikasi diubah.

Tabel berikut adalah titik awal penyelidikan. Ini bukan tabel untuk menentukan penyebab. Bandingkan operasi di sesi yang sama terlebih dahulu, lalu ubah perangkat, jalur, atau kondisi tampilan yang diperlukan.

Teks terlambat di beberapa aplikasi

Jika karakter terlambat satu per satu di beberapa aplikasi dalam sesi yang sama, bandingkan operasi yang sama juga dari perangkat lain atau jalur lain yang diizinkan. Cocokkan waktu pulang-pergi, penantian input di komputer tujuan, dan beban keseluruhan komputer tujuan; penyebab tidak ditentukan dari satu angka saja.

Hanya pengguliran yang tersendat

Meskipun mengetik terasa normal, menggulir halaman yang banyak fotonya memicu pembaruan layar pada area luas secara terus-menerus. Ubah resolusi sisi jarak jauh atau jumlah monitor satu per satu, lalu bandingkan pada halaman yang sama. Jika membaik, kompresi di komputer tujuan, transfer layar, dan decoding lokal menjadi sasaran penyelidikan berikutnya. Resolusi saja tidak dapat menunjukkan yang mana dari ketiganya yang menjadi penyebab. Lihat: Beban menurut isi layar dan resolusi.

Hanya satu aplikasi yang macet

Jika hanya aplikasi bisnis tempat tombol pencarian ditekan yang berhenti, bandingkan apakah Notepad dan sejenisnya di sesi yang sama merespons. Jika aplikasi lain berjalan, selidiki lebih dulu pemrosesan aplikasi sasaran, disk, serta permintaan ke DB atau folder bersama. Mengoperasikan aplikasi melalui RDP dan komunikasi RDP menjadi penyebab penantian adalah dua hal yang berbeda. Lihat: Faktor kinerja aplikasi dan backend.

Semua melambat saat pengguna bertambah

Jika beberapa pengguna melambat pada jam yang sama, tanyakan kepada administrator tentang keadaan sesi lain. Cocokkan beban CPU, memori, dan storage host bersama serta beban koneksi bersama dengan waktu munculnya gejala. Catatan atau proses pengguna lain tidak diakses tanpa izin, dan job mereka tidak dihentikan. Lihat: Sumber daya host bersama dan jumlah pengguna.

Melambat saat menyalin atau mencetak

Jika gangguan bertepatan dengan saat Anda mulai menyalin atau mencetak, jeda sementara hanya transfer yang diizinkan untuk dihentikan, lalu bandingkan. Catat apakah keadaan pulih setelah dijeda dan apakah melambat lagi saat dilanjutkan, lalu selidiki persaingan dengan transfer selain layar atau pengalihan perangkat. Perbandingan dengan menonaktifkan sekaligus perangkat yang diperlukan untuk pekerjaan tidak dilakukan. Lihat: Dampak pengalihan perangkat.

Membandingkan kondisi satu per satu

Semua pengaturan tidak perlu diubah secara berurutan. Pertama, buat acuan perbandingan, lalu pilih hanya pemeriksaan yang sesuai dengan gejala. Sebelum mengubah pengaturan atau menyambung ulang, simpan pekerjaan Anda dan catat nilai awal serta cara mengembalikannya. Jika hak akses atau fitur yang diperlukan tidak tersedia, fitur itu tidak dipaksa diaktifkan, melainkan diserahkan kepada administrator.

Operasi langsung di komputer tujuan dan operasi melalui RDP belum tentu berada dalam kondisi yang sama. Operasi yang cepat di layar fisik komputer tujuan dapat menjadi acuan, tetapi sesi dan kondisi rendering bisa berbeda. Samakan pengguna, data, dan keadaan aplikasi, dan jangan membatasi penyebab pada koneksi hanya karena “di layar fisik cepat”.

Membandingkan operasi yang sama

Siapkan pengguna, data, dan operasi yang sama. Di host bersama, pastikan sesi Anda sendiri, dan aplikasi atau proses pengguna lain tidak dihentikan. Penggunaan perangkat lain atau jalur lain juga terbatas pada lingkup yang diizinkan administrator.

1. Reproduksi operasi yang lambat dengan pengaturan awal, lalu catat waktu dan gejalanya.

   Ketik jumlah karakter yang kurang lebih sama di Notepad pada sesi jarak jauh yang sama dengan aplikasi bermasalah. Bedakan apakah hanya satu aplikasi atau seluruh sesi.

2. Periksa beban komputer tujuan dan perangkat lokal pada rentang waktu yang sama.

   Di Manajer Tugas, lihat CPU, memori, dan disk aplikasi sasaran di komputer tujuan, serta beban klien RDP di perangkat lokal. Periksa proses sasaran, bukan hanya nilai CPU keseluruhan. Lihat: Apa yang diperiksa saat menyelidiki beban.

3. Ubah hanya satu kondisi, yaitu perangkat lain, jalur lain yang diizinkan, atau kondisi tampilan, lalu ulangi operasi yang sama.

   Jika perbandingan ikut mengubah keadaan komputer tujuan atau aplikasi, catat juga perbedaan itu. Hasil dari perubahan beberapa kondisi tidak dianggap sebagai efek dari satu kondisi saja.

4. Kembalikan ke kondisi awal, lalu periksa ulang operasi yang sama.

   Jika tetap cepat setelah dikembalikan, perubahan beban sementara dan sejenisnya juga mungkin terjadi. Tanpa memastikan bahwa perubahan itulah yang berhasil, catat kondisi yang membuat gejala muncul kembali.

Hasil dari keadaan awal, setelah perubahan, dan setelah dikembalikan menjadi lengkap, sehingga Anda dapat membandingkan kondisi mana yang berkorespondensi dengan gejala. Kondisi yang membawa perbaikan adalah petunjuk penyelidikan, dan dengan sendirinya tidak membuktikan akar penyebab.

flowchart TB
    accTitle: Batasi kondisi yang diubah dalam satu waktu
    accDescr: Alur menentukan operasi yang dapat direproduksi dalam keadaan awal, membandingkan dengan mengubah satu kondisi saja, dan juga memeriksa hasil setelah dikembalikan.
    A["Operasi sama dengan pengaturan awal"] --> B["Ubah satu kondisi saja"]
    B --> C["Ulangi operasi yang sama"]
    C --> D["Kembalikan dan periksa ulang"]
    D --> E["Catat kondisi yang membaik"]

Gambar 10: Ulangi operasi yang sama dalam keadaan awal, setelah perubahan, dan setelah dikembalikan, lalu catat kondisi yang berubah.

Membandingkan resolusi sisi jarak jauh

Bandingkan ketika pembaruan layar terasa berat, misalnya saat menggulir. Catat resolusi dan jumlah monitor sebelum perubahan, simpan pekerjaan, lalu sambungkan ulang. Pengaturan yang mengurangi keterbacaan layar atau teks yang diperlukan untuk pekerjaan tidak dipakai terus-menerus apa adanya.

1. Ubah hanya salah satu, jumlah monitor atau resolusi.

   Di mstsc, perbandingan dapat dilakukan dengan pengaturan “Tampilan” sebelum terhubung atau dengan menentukan lebar dan tinggi. Lihat: Penentuan layar di mstsc.

2. Pastikan ukuran sebenarnya desktop komputer tujuan sudah berubah, lalu gulir halaman yang sama.

   Jika hanya jendela lokal yang diperkecil, bisa jadi desktop yang besar hanya ditampilkan dalam skala kecil. Bedakan resolusi dinamis dan smart sizing, lalu periksa syarat dukungan klien yang dipakai. Lihat: Resolusi desktop dan skala tampilan.

3. Kembalikan ke pengaturan awal, ulangi operasi yang sama, lalu bandingkan beban di kedua ujung dan gerakan layar.

   Jika Anda mengubah sekaligus ke resolusi rendah dan satu monitor, hasilnya hanya perbandingan kasar. Jika membaik, kembalikan satu per satu untuk memisahkan pengaruhnya.

Jika membaik, petunjuknya ada di lingkup pemrosesan layar dan transfer layar. 3840×2160 memiliki jumlah piksel 4 kali 1920×1080, tetapi volume komunikasi tidak selalu menjadi 4 kali lipat. Volume itu berubah menurut bagian yang berubah dan kompresi, dan perubahan resolusi juga memengaruhi pemrosesan di kedua ujung. Lihat: Hubungan jumlah piksel dan volume komunikasi, Pemeriksaan pemrosesan layar.

flowchart TB
    accTitle: Apa yang diketahui dari perbandingan dengan resolusi lebih rendah
    accDescr: Menurunkan resolusi sisi jarak jauh dapat mengubah beban pemrosesan layar maupun transfer, sehingga perbaikan saja tidak dapat membatasi penyebab pada koneksi.
    A["Turunkan resolusi sisi jarak jauh"] --> S
    subgraph S["Pemrosesan yang berubah"]
    direction TB
    B["Pemrosesan layar di tujuan"] ~~~ C["Jumlah info yang dikirim"]
    C ~~~ D["Pemrosesan tampilan lokal"]
    end

Gambar 11: Perubahan resolusi adalah perbandingan yang memengaruhi bukan hanya koneksi, tetapi juga pemrosesan layar di komputer tujuan dan perangkat lokal.

Mencocokkan salin/cetak dengan gejala

Yang dijeda sementara hanyalah proses yang diizinkan untuk dihentikan, seperti transfer yang Anda mulai sendiri. Proses pencadangan dan keamanan perusahaan serta job pengguna lain tidak dihentikan. Pengalihan perangkat audio dan input yang diperlukan untuk pekerjaan tidak dinonaktifkan sekaligus.

1. Sebelum dan selama penyalinan, sinkronisasi cloud, atau pencetakan berlangsung, catat operasi yang sama dan bebannya.

   Selain layar, informasi drive, printer, dan sebagainya juga mengalir melalui RDP. Pengalihan yang memungkinkan perangkat lokal dipakai di komputer tujuan dapat menambah beban komunikasi dan pemrosesan selama digunakan. Lihat: Dampak pengalihan perangkat.

2. Jeda sementara transfer sasaran dalam batas yang diizinkan, lalu periksa ulang operasi yang sama.

   Jika bisa dilanjutkan untuk dibandingkan, catat juga gejala setelah dilanjutkan. Saat mencoba pengalihan perangkat yang tidak diperlukan pun, ubah satu per satu dan pastikan bisa dikembalikan ke pengaturan awal.

Anda dapat menilai apakah dimulainya transfer berkorespondensi dengan gangguan, dan jeda dengan pemulihan. Jika korespondensinya terlihat, cocokkan transfer selain layar dan beban sumber daya bersama dengan catatan administrator.

flowchart TB
    accTitle: Melihat sebelum dan sesudah gangguan pada sumbu waktu yang sama
    accDescr: Catat operasi yang sama dan beban sebelum transfer, selama transfer, dan setelah dihentikan, lalu bandingkan hubungan antara gangguan dan pekerjaan.
    A["Operasi dan beban sebelum transfer"] --> B["Operasi dan beban selama transfer"]
    B --> C["Operasi dan beban setelah dihentikan"]
    C --> D["Gangguan dan pemulihan berkorespondensi?"]

Gambar 12: Lihat bagaimana kelambatan operasi yang sama dan bebannya berubah sebelum transfer, selama transfer, dan setelah dihentikan.

Mengukur titik penantian

Dari perangkat lokal, periksa perjalanan pulang-pergi jaringan dan koneksi TCP; di komputer tujuan, periksa penantian di antrean input dan pembaruan layar. Setiap angka hanya mengukur rentang yang terbatas, jadi baca hasilnya dengan membandingkannya dengan tabel di “Cakupan hasil pengukuran”.

Memeriksa ICMP dan koneksi TCP

Langkah ini dijalankan di perangkat Windows lokal. Sasarannya hanya konfigurasi yang terhubung langsung ke host RDP yang memakai TCP 3389 standar melalui LAN kantor atau VPN yang diizinkan. Untuk konfigurasi melalui RD Gateway atau Azure Virtual Desktop atau yang memakai port khusus, tentukan sasaran pemeriksaan bersama administrator. Port tidak dibuka untuk publik dan firewall tidak diubah.

1. Masukkan tujuan yang diizinkan, lalu catat hasil respons ICMP dan koneksi TCP.

   $target = Read-Host 'Nama atau alamat IP host RDP yang diizinkan untuk diselidiki'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'Tentukan tujuan koneksi.'
   }
       
   # Lihat waktu respons ICMP beberapa kali. Kegagalan saja tidak dijadikan dasar bahwa RDP tidak tersambung.
   ping.exe -n 20 $target
       
   # Pemeriksaan ini hanya untuk konfigurasi yang terhubung langsung ke TCP 3389 standar.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. Cocokkan hasil pada jam lambat dan saat normal dengan waktu gejala serta jalur koneksi yang sebenarnya.

   ping sebanyak 20 kali adalah pengamatan singkat. Catat fluktuasi nilai dan tidak adanya respons, tetapi ICMP juga bisa diblokir. Penghentian yang terputus-putus tidak disangkal dari nilai rata-rata saja; gunakan informasi koneksi dan catatan komunikasi milik administrator. Lihat: Apa yang diukur ping.

TcpTestSucceeded: True berarti koneksi TCP ke port yang ditentukan berhasil. Bandwidth, UDP, operasi setelah autentikasi, dan kelancaran layar tidak diukur. Test-NetConnection tidak memiliki switch -UDP untuk memeriksa UDP. Lihat: Sintaks dan hasil Test-NetConnection.

Penilaian dilakukan dengan tetap memperhitungkan perbedaan jalur dan layanan. Pada RD Gateway dan sejenisnya, jalur ICMP atau koneksi TCP langsung ke host bisa tidak sama dengan jalur RDP yang sebenarnya. Di Azure Virtual Desktop, RTT dan estimasi bandwidth per koneksi dapat digunakan, tetapi fitur diagnostik itu khusus untuk layanan tersebut. Penghentian singkat tidak disangkal hanya dari nilai rata-rata. Lihat: Log kualitas koneksi Azure Virtual Desktop.

flowchart TB
    accTitle: Jalur yang diperiksa dan jalur RDP yang sebenarnya
    accDescr: Pada konfigurasi yang memakai RD Gateway dan sejenisnya, jalur ICMP atau koneksi TCP langsung dari perangkat lokal ke host bisa tidak sama dengan jalur RDP yang sebenarnya.
    A["Perangkat lokal"] -->|"ICMP, TCP langsung"| C["Host RDP"]
    A -->|"RDP sebenarnya"| B["RD Gateway, dll."]
    B --> C

Gambar 13: ICMP atau koneksi TCP langsung ke host dan RDP yang sebenarnya bisa melewati jalur yang berbeda.

Mengukur penantian di antrean input

User Input Delay mengukur penantian sejak input masuk ke antrean di komputer tujuan sampai proses mengambilnya. Ini bukan total waktu dari menekan tombol sampai karakter terlihat. Lihat: Definisi User Input Delay.

Pemeriksaan dilakukan di dalam sesi jarak jauh pada komputer tujuan. Syarat dukungan dari Microsoft adalah Windows 10 versi 1809 atau yang lebih baru dan Windows Server 2019 atau yang lebih baru. Pada sasaran ini, penambahan registri untuk mengaktifkannya tidak diperlukan. Periksa nama tampilan, hak akses, dan ada tidaknya counter; jika tidak tersedia, catat fakta itu dan konsultasikan dengan administrator. Lihat: Syarat dukungan dan pengaturan.

1. Di PowerShell pada sesi yang sama, catat waktu dan ID sesi.

   Get-Date -Format 'yyyy-MM-dd HH:mm:ss.fff zzz'
   (Get-Process -Id $PID).SessionId
   query.exe session
       
   

   Untuk menanyakan sesi pengguna lain, hak akses tambahan mungkin diperlukan. Nama instance standar untuk proses sasaran adalah SessionID:ProcessID <Process Image>. Pastikan nilai milik pengguna lain atau proses dengan nama yang sama tidak tercampur hanya karena berpatokan pada ID sesi. Lihat: Hak akses query session, Identifikasi instance.

2. Di perfmon.exe, tambahkan User Input Delay per Process atau User Input Delay per Session yang tersedia.

   Pilih proses atau sesi sasaran, dan pada awalnya amati dengan interval default 1 detik. Bedakan instance agregat yang menggabungkan beberapa sesi dari nilai sesi individual.

3. Reproduksi operasi yang inputnya lambat, lalu bandingkan penantian antrean dengan waktu gejala.

   Untuk sasaran pengukuran individual, yang dilihat adalah waktu tunggu maksimum dalam interval pengukuran. Meskipun nilainya rendah, pemrosesan setelah aplikasi mengambil input dan keterlambatan sampai hasilnya kembali ke perangkat lokal tetap ada.

Anda dapat memeriksa apakah ada penantian di antrean input komputer tujuan. Ini adalah indikator yang berbeda dari waktu yang dirasakan pengguna, yang mencakup perjalanan pulang-pergi jaringan dan tampilan di perangkat lokal. Lihat: Arti nilai maksimum dan interval pengukuran.

flowchart TB
    accTitle: Rentang yang diukur User Input Delay
    accDescr: Rentang pengukurannya adalah sejak input masuk ke antrean di komputer tujuan sampai aplikasi mengambilnya; komunikasi dan tampilan layar sebelum dan sesudahnya tidak termasuk.
    A["Input tiba dari lokal"] --> B["Masuk antrean input di tujuan"]
    B -->|"Bagian yang diukur"| C["Aplikasi mengambil input"]
    C --> D["Pemrosesan aplikasi dan transfer layar"]
    D --> E["Tampil di perangkat lokal"]

Gambar 14: Yang diukur adalah penantian di antrean input komputer tujuan. Ini berbeda dari total waktu sampai hasilnya terlihat di perangkat lokal.

Memeriksa pembaruan layar dan alasan frame dilewati

Siapkan operasi yang terus memperbarui layar, seperti menggulir. Ketersediaan dan lokasi pengukuran counter RemoteFX Graphics perlu diperiksa menurut OS, konfigurasi host, dan hak akses. Di sini kita hanya membaca counter yang tersedia. Ini bukan langkah untuk memasang atau mengaktifkan fitur RemoteFX lama. Lihat: Syarat penerapan counter Graphics.

1. Periksa nama sesi sasaran dengan query session atau qwinsta, lalu pilih instance counter yang sesuai.

2. Selama operasi yang memperbarui layar, bandingkan Input Frames/Second dan Output Frames/Second.

   Jika output lebih sedikit daripada input, sebagian frame layar dilewati di tengah jalan. Periksa nilai Frames Skipped/Second menurut jenis kekurangan sumber daya: komputer tujuan, jaringan, atau klien.

3. Cocokkan alasan frame dilewati dengan beban di kedua ujung dan pada komunikasi, lalu periksa juga Average Encoding Time.

   Jika waktu encoding panjang, selidiki proses kompresi di komputer tujuan. Jika jumlah frame sudah sedikit dari sisi input, ada juga kemungkinan aplikasi tidak sering memperbarui layar. Jumlah frame yang rendah pada layar yang diam bukanlah kelainan.

Dari input dan output selama pembaruan layar, alasan frame dilewati, dan waktu encoding, Anda dapat mempersempit sasaran penyelidikan. Klasifikasi counter adalah petunjuk, dan penilaiannya dilakukan bersama beban yang sebenarnya dan konfigurasi koneksi. Lihat: Cara membaca jumlah frame dan waktu encoding.

flowchart TB
    accTitle: Mempersempit sasaran penyelidikan dari frame yang dilewati
    accDescr: Selama operasi yang memperbarui layar, bandingkan jumlah frame input dan output, lalu dengan counter alasan frame dilewati sebagai petunjuk, cocokkan dengan beban pemrosesan, komunikasi, dan tampilan.
    A["Bandingkan input/output saat gulir"] --> B["Jika output sedikit, cek frame dilewati"]
    B --> C["Lihat counter per alasan"]
    C --> D["Cocokkan beban tujuan, jaringan, lokal"]

Gambar 15: Bandingkan input dan output selama pengguliran, lalu cocokkan alasan frame dilewati dengan beban komputer tujuan, koneksi, dan perangkat lokal.

Diagram konseptual transfer layar dan dokumen lama tidak digeneralisasi ke semua konfigurasi. Ada juga konfigurasi yang mentransfer video dan audio dengan mekanisme lain. Dokumentasi counter Graphics juga memuat penjelasan tentang konfigurasi lama, sehingga angka yang tercantum tidak dibaca sebagai spesifikasi umum bahwa “semua RDP maksimal 30fps”. Periksa sasaran penerapan fitur dan angka sebelum menggunakannya. Lihat: Transfer layar dan beban kerja, Dokumentasi counter Graphics.

Cakupan hasil pengukuran

Angka yang rendah tidak disamakan dengan operasi yang nyaman. Cakupan setiap indikator dapat diperiksa di dokumentasi Microsoft yang ditunjukkan dalam langkah-langkah.

Pengaturan jaringan dan GPU

Pengaturan UDP dan GPU dipilih sesuai dengan apa yang diketahui dari perbandingan dan pengukuran. Jika komunikasi jaringan dicurigai, periksa dulu metode koneksi dan jalurnya; jika pemrosesan layar dicurigai, periksa dulu tahap tempat GPU digunakan.

Memeriksa TCP/UDP dan jalur koneksi

Jika perbandingan dan pengukuran menunjukkan komunikasi jaringan patut dicurigai, periksa bersama administrator klien yang dipakai, jalur, dan kebijakan yang diterapkan. Jika perubahan pengaturan diperlukan pun, batasi pada lingkup yang disetujui, dan catat nilai sebelum perubahan serta cara pemulihannya. Firewall dan autentikasi tidak dinonaktifkan, dan port RDP tidak dibuka langsung ke internet.

1. Periksa TCP/UDP dan jalur yang sebenarnya melalui informasi koneksi, log diagnostik produk, dan catatan komunikasi milik administrator.

   RDP menggunakan TCP atau UDP sesuai konfigurasi dan kondisi komunikasi. Pada “Select RDP transport protocols”, Anda dapat memilih pengaturan yang memakai UDP atau TCP, atau pengaturan yang hanya memakai TCP. Ada juga perilaku yang memakai TCP jika koneksi UDP tidak terbentuk, sehingga keberhasilan koneksi saja tidak menunjukkan metodenya. Lihat: Pemilihan dan fallback RDP transport.

2. Cocokkan waktu gejala dengan jalur dan metode, lalu bandingkan hanya pengaturan yang diperlukan, satu per satu.

   Pengaturan tidak diubah secara seragam dengan anggapan “mematikan UDP akan mempercepat”. Samakan kondisi VPN dan gateway, operasi, serta kondisi tampilan, lalu bandingkan; kembalikan perubahan yang tidak diperlukan.

Setelah memahami metode dan jalurnya, Anda dapat mencatat hubungan antara perubahan dan gejala. Mengubah ke TCP saja tidak selalu membuatnya lebih cepat.

flowchart TB
    accTitle: Periksa metode koneksi sebelum membandingkan pengaturan komunikasi
    accDescr: Bedakan koneksi langsung biasa dari koneksi melalui gateway atau layanan, periksa jalur dan metode yang sebenarnya, lalu lakukan perbandingan yang diizinkan.
    A["Klien yang dipakai dan konfigurasi koneksi"] --> B["Periksa jalur dan TCP/UDP sebenarnya"]
    B --> C["Cocokkan dengan waktu gejala"]
    C --> D["Bandingkan pengaturan perlu satu per satu"]

Gambar 16: Pastikan metode koneksi dan jalur yang sedang dipakai, cocokkan dengan gejala, lalu bandingkan hanya pengaturan yang diperlukan.

RDP Shortpath adalah mekanisme Azure Virtual Desktop. Mekanisme ini membentuk jalur UDP untuk layanan tersebut dan, tergantung konfigurasi, memakai jalur langsung atau relay. Jika tidak dapat dibentuk, koneksi kembali ke koneksi berbasis TCP. Pengaturannya tidak dapat disamakan dalam satu tabel dengan kasus terhubung langsung ke PC kantor dengan mstsc. Lihat: Jalur dan fallback RDP Shortpath.

flowchart TB
    accTitle: Jalur dan fallback RDP Shortpath
    accDescr: RDP Shortpath di Azure Virtual Desktop mencoba membentuk jalur UDP; jika berhasil, jalur langsung atau relay dipakai sesuai konfigurasi, dan jika gagal, koneksi kembali ke koneksi berbasis TCP.
    A["RDP Shortpath"] --> B{"Jalur UDP"}
    B -->|"Terbentuk"| C["Langsung atau relay"]
    B -->|"Gagal"| D["Kembali ke berbasis TCP"]

Gambar 17: Jika jalur UDP tidak dapat dibentuk, RDP Shortpath kembali ke koneksi berbasis TCP.

Memeriksa penggunaan GPU untuk pemrosesan layar

Periksa ini jika perbandingan dan pengukuran menunjukkan pemrosesan layar patut dicurigai. Periksa hasil pengukuran pemrosesan layar serta OS, driver, kebijakan, dan klien yang didukung. Pengaturan tidak diubah hanya karena GPU terpasang. Dapatkan persetujuan administrator dan siapkan cara mengembalikan terlebih dahulu.

1. Pisahkan rendering aplikasi di komputer tujuan, encoding RDP, dan decoding lokal, lalu pilih tahap yang dicurigai.

   Meskipun ada GPU, belum tentu semua tahap memakai GPU. Dalam dokumentasi konfigurasi Microsoft untuk Azure Virtual Desktop pun, rendering sesi jarak jauh dan hardware encoding frame dikonfigurasi dan diperiksa secara terpisah. Lihat: Konfigurasi dan verifikasi GPU untuk rendering dan encoding.

2. Periksa penggunaan yang sebenarnya sesuai prosedur produk sasaran, lalu ukur operasi yang sama sebelum dan sesudah perubahan yang diperlukan.

   Jika waktu kompresi panjang, selidiki penggunaan GPU untuk encoding. Mengubah pengaturan encoding untuk aplikasi yang menunggu di antrean input berarti menyasar tempat yang salah. Keterbacaan teks dan kelancaran video juga memerlukan pilihan kualitas gambar, volume komunikasi, dan beban pemrosesan yang berbeda. Lihat: Perbedaan menurut beban kerja.

Tidak berhenti pada ada atau tidaknya GPU, Anda dapat mencatat apakah GPU digunakan pada tahap yang bermasalah dan bagaimana beban serta respons operasi yang sama berubah. Perubahan yang tidak membawa perbaikan dikembalikan setelah dikonfirmasi dengan administrator.

flowchart TB
    accTitle: Memeriksa penggunaan GPU per tahap
    accDescr: Pisahkan rendering aplikasi di komputer tujuan, encoding RDP, dan decoding lokal; karena meskipun ada GPU belum tentu semua tahap memakainya, periksa penggunaannya pada tahap yang dicurigai.
    A["Rendering aplikasi di tujuan"] --> B["Encoding RDP"]
    B --> C["Decoding lokal"]
    C -.- D["Periksa GPU per tahap"]

Gambar 18: Meskipun ada GPU, belum tentu rendering, encoding, dan decoding semuanya memakai GPU.

Verifikasi ulang dan serah terima

Perbaikan dipastikan bukan hanya dari operasi yang sama dapat dilakukan tanpa hambatan setelah perubahan, tetapi juga dari terjaganya kualitas gambar, perangkat, dan fungsi bisnis yang diperlukan. Cocokkan juga dengan hasil setelah dikembalikan ke kondisi awal. Jika hanya pulih sesaat, penyebabnya tidak dipastikan; catat termasuk jam sibuk dan proses yang berjalan bersamaan.

flowchart TB
    accTitle: Urutan memastikan perbaikan
    accDescr: Menunjukkan bahwa setelah perubahan, selain memastikan operasi yang sama dapat dilakukan tanpa hambatan, pastikan juga kualitas gambar, perangkat, dan fungsi bisnis yang diperlukan tetap terjaga, cocokkan dengan hasil setelah dikembalikan ke kondisi awal, dan penyebab tidak dipastikan hanya dari pemulihan sesaat.
    A["Coba operasi sama setelah perubahan"] --> B["Pastikan kualitas, perangkat, fungsi bisnis"]
    B --> C["Cocokkan dengan hasil kondisi awal"]
    C -.- D["Pulih sesaat belum memastikan"]

Gambar 19: Selain hasil operasi yang sama, cocokkan juga fungsi yang diperlukan dan hasil setelah dikembalikan.

Serah terima jika belum terselesaikan

Tidak membaik, tidak dapat direproduksi, atau counter tidak tersedia pun merupakan hasil yang berguna. Pisahkan perbandingan yang sudah dilakukan dan pemeriksaan yang tidak dapat dilakukan, lalu serahkan kepada administrator dan pengembang dengan catatan berikut. Hapus informasi bisnis yang tidak diperlukan untuk penyelidikan, seperti nama pengguna dan tujuan koneksi, dari log yang dibagikan.

Waktu gejala muncul dan zona waktu:
OS komputer tujuan, klien yang dipakai, dan versinya:
Langsung / VPN / RD Gateway / Azure Virtual Desktop, dll.:
Operasi dan aplikasi yang lambat, respons aplikasi lain di sesi yang sama:
Resolusi dan jumlah monitor sisi jarak jauh:
Salin, cetak, dll. yang berjalan bersamaan:
Satu kondisi yang diubah dan hasil setelah dikembalikan:
Beban dan counter yang diamati di komputer tujuan dan lokal:

Tambahkan juga apakah TCP/UDP yang sebenarnya dapat dipastikan, item yang tidak dapat diperiksa karena kurangnya hak akses dan sebagainya, serta pengaturan yang dapat diterima secara bisnis. Menyampaikan “di Notepad bisa mengetik normal, tetapi berhenti saat menggulir foto” lebih memungkinkan petugas berikutnya menyelidiki dengan kondisi yang sama daripada menyampaikan “koneksinya lambat”.

Pengguna menyimpan operasi yang mereproduksi gejala dan hasil perbandingan, sedangkan administrator mencocokkan catatan jalur koneksi, host bersama, dan sesi. Fakta bahwa penantian terjadi di atas RDP saja tidak berarti proses yang menyebabkan penantian itu juga RDP. Lihat: Pembagian peran host dan backend.

Pengembang aplikasi mencatat secara terpisah penerimaan event input, awal dan akhir pemrosesan DB dan file, serta penerapannya ke UI. Desain yang tidak membiarkan pekerjaan berat menetap di thread UI juga dipertimbangkan. Namun, log selesainya pemrosesan di komputer tujuan bukan catatan selesainya tampilan di perangkat lokal. Lihat: Pemisahan pemrosesan untuk menjaga responsivitas UI.

Artikel terkait

• Bagaimana memahami isolasi sesi di Windows
• Memilah masalah disk 100% di Windows dengan aman
• Mengapa “sisa 1 detik” tidak kunjung selesai?

Referensi

Berikut adalah sumber primer dari Microsoft Learn. Isi yang dirujuk telah diperiksa pada 17 September 2026. Saat membacanya, bedakan syarat penerapan per produk, dan perhatikan bahwa ini bukan hasil pengukuran nyata yang dilakukan dalam artikel ini.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. Perbedaan antara RTT dan keterlambatan dari pengambilan layar di komputer tujuan sampai tampilan di perangkat lokal. Fitur diagnostiknya sendiri ditujukan untuk Azure Virtual Desktop.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. Hubungan antara isi layar, resolusi, pembaruan frame, kompresi, cache, dan volume komunikasi.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. Cara memeriksa input dan output layar, alasan frame dilewati, dan waktu encoding. Karena memuat penjelasan tentang konfigurasi lama, batas angkanya tidak digeneralisasi ke semua RDP.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. Beban host bersama, komunikasi dari komputer tujuan ke backend, dan dampak pengalihan perangkat.
• Microsoft Learn, Threading model. Thread UI dan Dispatcher di WPF, serta pemisahan pemrosesan untuk menjaga responsivitas.
• Microsoft Learn, mstsc. Penentuan lebar dan tinggi Desktop Jauh serta beberapa monitor.
• Microsoft Learn, Supported RDP properties. Perbedaan resolusi desktop, resolusi dinamis, dan smart sizing. Periksa klien yang didukung dan syarat penerapan per produk.
• Microsoft Learn, ping. Pemeriksaan respons dengan ICMP Echo dan opsinya.
• Microsoft Learn, Test-NetConnection. Pemeriksaan koneksi TCP dan arti output-nya.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. Interval pengukuran User Input Delay, OS sasaran, instance, dan arti nilai maksimum.
• Microsoft Learn, query session. Informasi sesi dan hak akses yang diperlukan untuk menanyakan sesi lain.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. Pemilihan TCP/UDP yang digunakan RDP dan fallback-nya.
• Microsoft Learn, RDP Shortpath. Jalur UDP untuk Azure Virtual Desktop dan perilaku ketika jalur itu tidak dapat dibentuk.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. Konfigurasi dan verifikasi GPU yang memisahkan rendering dan encoding frame.

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik yang lebih dekat.

Topik terkait

Ini adalah halaman topik yang dekat dengan tema ini. Dari artikel, Anda dapat melanjutkan ke layanan terkait dan artikel lainnya.

Layanan yang terkait dengan topik ini

Artikel ini terhubung ke halaman layanan berikut. Silakan lihat dari pintu masuk yang dekat dengan situasi Anda.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Mengapa input RDP lambat padahal uji kecepatan menunjukkan ratusan Mbps?

Kecepatan mengangkut data dalam jumlah besar dan waktu sampai respons atas suatu operasi kembali adalah dua hal yang berbeda. Pengiriman input, pemrosesan aplikasi di komputer tujuan, kompresi layar, transfer, dan tampilan di perangkat lokal ikut berperan. Selain itu, jalur komunikasi ke server uji kecepatan juga berbeda dari jalur ke tujuan koneksi RDP.

Teks bisa diketik dengan normal, tetapi hanya pengguliran yang tersendat. Apakah ini masalah koneksi?

Penyebabnya tidak bisa dipersempit hanya pada koneksi. Ketika pembaruan layar bertambah, ada kemungkinan salah satu dari rendering dan kompresi di komputer tujuan, komunikasi jaringan, atau decoding dan tampilan di perangkat lokal tidak mampu mengimbangi. Ubah resolusi sisi jarak jauh atau jumlah monitor satu per satu untuk membandingkan, dan bila perlu periksa counter yang terkait dengan rendering.

Jika ping cepat, apakah komunikasi RDP berarti normal?

Itu saja tidak cukup untuk menilai. ping mengukur respons terhadap ICMP, bukan transfer layar RDP maupun pemrosesan aplikasi. Pada konfigurasi yang memakai RD Gateway dan sejenisnya, jalurnya pun bisa tidak sama. Jika tidak ada respons, bedakan juga antara ICMP yang diblokir dan RDP itu sendiri yang tidak tersambung.

Apakah User Input Delay adalah waktu dari menekan tombol sampai karakter muncul?

Bukan. Ini adalah counter yang mengukur waktu tunggu sejak input masuk ke antrean di komputer tujuan sampai proses mengambilnya. Nilainya bukan keterlambatan yang dirasakan pengguna, yang mencakup perjalanan pulang-pergi jaringan, pemrosesan aplikasi setelah input diambil, serta kompresi, decoding, dan tampilan layar.

Apakah UDP sebaiknya dinonaktifkan ketika RDP terasa berat?

Hal ini tidak dianjurkan untuk semua kasus. Pertama, periksa metode koneksi dan jalur yang sebenarnya serta kebijakan yang diterapkan. Ada kalanya UDP tidak dapat digunakan sehingga koneksi sudah fallback ke TCP, dan mengubahnya menjadi TCP saja tidak selalu membuatnya lebih cepat. Dengan izin administrator, samakan kondisinya lalu bandingkan, dan kembalikan perubahan yang tidak diperlukan.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Perwakilan KomuraSoft LLC

Berfokus pada pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, dengan keunggulan pada proyek yang masih memiliki aset yang sudah ada dan investigasi gangguan yang penyebabnya sulit terlihat.