Bağlantı hızlı olduğu hâlde RDP neden yavaş? — Girdi, çizim ve iletişimi ayırarak incelemek

Hız testinde yüzlerce Mbps çıkıyor, ama Uzak Masaüstü’nde karakterler biraz gecikerek beliriyor. Fotoğraf dolu bir sayfayı kaydırınca ekran takılıyor. İş uygulamasında aramaya bastığınızda yalnızca o an birkaç saniye donuyor. Bu tür bir “bağlantı hızlı ama RDP yavaş” durumunu incelemeye nereden başlamalı?

RDP’de işlemlere verilen yanıt yalnızca bağlantının aktarım hızıyla belirlenmez. Hız testi hızlı çıksa bile iletişimin gidiş-dönüşü, uzak bilgisayardaki uygulamanın girdi beklemesi, ekranın kodlanması ya da yerel bilgisayardaki kod çözme ve görüntülemeden herhangi birinde bekleme olabilir. Önce “hangi işlemin yavaş olduğunu” ayırın ve aynı işlemi her seferinde tek bir koşulu değiştirerek karşılaştırın. Karşılaştırma ve ölçümle incelenecek yeri daraltın; UDP ve GPU ayarlarını bu sonuçlara göre seçin. Bkz. bağlantı kalitesinde ölçülen aralıklar, oturum ana bilgisayarının performans etkenleri.

Ancak incelenecek yer daraltıldığı aşamada kök neden henüz kesinleşmemiştir. Çözünürlüğü düşürünce iyileşme olsa bile yalnızca iletişim değil iki uçtaki ekran işleme de değiştiği için “neden bağlantıymış” diye kesin hüküm vermeyiz. Ölçtüğünüz aralıkları ölçmediklerinizden ayırarak sonuçları kaydedin.

Bu makalede bağlantı kurulduktan sonraki girdi, kaydırma ve uygulama yanıtlarını ayrıştırıyoruz. Belirtiler benzer olsa da neden her zaman tek değildir. “Oturum açma ekranının gelmesi uzun sürüyor” ya da “yalnızca kimlik doğrulamada takılıyor” gibi durumları, bağlantının kurulması ve kimlik doğrulama kayıtlarından incelenecek ayrı bir sorun olarak ele alıyoruz.

Ana hedef kitle, Windows’un “Uzak Masaüstü Bağlantısı” (mstsc) uygulamasıyla Windows 11’e veya Windows Server’a bağlanan kullanıcılar ve yöneticilerdir. Komut örnekleri Windows PowerShell 5.1 içindir. Bağlı bir oturumda aynı işlemin yeniden üretilebildiği varsayılmaktadır.

Doğrudan bağlantı, VPN, RD Gateway ve Azure Virtual Desktop’ta yol, kullanılabilen tanılama bilgileri ve ayarların uygulandığı yer farklıdır. TCP 3389 kontrol örneği, standart bağlantı noktasını kullanan bir RDP ana bilgisayarına izin verilmiş doğrudan bağlantılarla sınırlıdır. Azure Virtual Desktop belgelerindeki tanılama özelliklerini ve GPU ayarlarını genel şirket bilgisayarlarına olduğu gibi uygulamayız.

Şirket cihazlarında inceleme, yöneticinin izin verdiği kapsamda yapılır. Paylaşılan ana bilgisayarlarda kendi oturumunuzu ve hedef süreci belirleyin; başka kullanıcıların kayıtları gerekiyorsa yöneticiden isteyin. Performans sayaçlarının kullanılabilirliği, görünen adları ve gereken izinler her ortamda ayrıca kontrol edilir.

Burada gösterilen kontrol yöntemleri resmî belgelere dayanır. Belirli bir cihazda arızayı yeniden üretip giderdiğimize dair bir ölçüm raporu değildir. Sayısal örnekler, açıklama amaçlı varsayımlar olduğu belirtilerek verilir.

Mekanizmayı bir sonraki “Aktarım hızı ve gidiş-dönüş süresi” bölümünden başlayarak sırayla okuyabilirsiniz. Belirtiden başlamak istiyorsanız “Belirtiye göre ilk karşılaştırma” bölümüne geçin. Uygulama adımları “Koşulları tek tek karşılaştırma” ve “Beklemenin yerini ölçme” bölümlerindedir.

Diyagramda düz çizgi her zaman geçerli olan bir ilişkiyi, kesikli çizgi ise koşullu bir ilişkiyi gösterir (koşullar, ayrıntı sayfasında her ilişki için verilmiştir). İlişkilerin tam listesi (toplam 7, kanıt ve kesinlik derecesiyle birlikte) ve ana kavramların tanımları bilgi haritası ayrıntı sayfasında (Japonca) toplanmıştır. Veri: JSON-LD / Turtle

Aktarım hızı ve gidiş-dönüş süresi

RDP (Remote Desktop Protocol), yerel cihaz ile uzak bilgisayar arasında girdi, ekran bilgisi ve benzeri verileri alıp veren bir protokoldür. Yalnızca ekranı ve girdiyi değil, cihaz yeniden yönlendirme ve yazdırma gibi bilgileri de taşır. Bkz. RDP’nin aktardığı bilgiler.

Bağlantının aktarım hızı, saniyede ne kadar veri taşıyabildiğini gösterir. Hız testindeki “500 Mbps” bu miktarla ilgili bir sayıdır. Bir işlem yaptıktan sonra yanıtın gelmesine kadar geçen süreyi gösteren bir sayı değildir. Bkz. RDP bant genişliği gereksinimleri.

flowchart TB
    accTitle: Hız testindeki sayının gösterdiği şey
    accDescr: Hız testindeki 500 Mbps değerinin saniyede taşınabilen veri miktarını gösteren bir sayı olduğunu ve işlemden sonra yanıtın gelmesine kadar geçen süreden farklı bir sayı olduğunu gösterir.
    A["Hız testi: 500 Mbps"] --> B["Saniyede taşınan veri miktarı"]
    B -.->|"Ayrı bir sayı"| C["Yanıtın gelme süresi"]

Şekil 1: Hız testindeki sayı taşınabilen miktarı gösterir; yanıtın gelmesine kadar geçen süreyi göstermez.

Gidiş-dönüş süresi (RTT), iletişimin karşı tarafa ulaşıp geri dönmesine kadar geçen süredir. Aktarım hızını artırmak ile gidiş-dönüş süresini kısaltmak arasındaki fark, bir yolun şerit sayısını artırmak ile hedefe olan mesafeyi kısaltmak arasındaki farka benzer. Büyük miktarda dosya taşıma kapasitesi artsa bile gidiş-dönüş süresi aynıysa işlemlere yanıt beklemesi olduğu gibi kalır. Bkz. RTT ve ekran görüntüleme gecikmesi.

flowchart TB
    accTitle: Aktarım hızını ve gidiş-dönüş süresini yola benzetmek
    accDescr: Aktarım hızını artırmayı yolun şeritlerini artırmaya, gidiş-dönüş süresini kısaltmayı hedefe olan mesafeyi kısaltmaya benzeten bir şekildir.
    A["Aktarım hızını artırmak"] -->|"Yolda"| B["Şerit sayısını artırmak"]
    B ~~~ C["Gidiş-dönüşü kısaltmak"]
    C -->|"Yolda"| D["Mesafeyi kısaltmak"]

Şekil 2: Şeritleri artırmak hedefe olan mesafeyi kısaltmaz.

Tek bir karakterin sonucu dönene kadar

Uzaktaki Not Defteri’ne tek bir karakter yazdığınızı düşünün. Not Defteri uzak bilgisayarda çalışır. Açıklama amacıyla işlemin ulaşması için 50 milisaniye, sonucun ekran bilgisinin dönmesi için 50 milisaniye varsayılırsa iletişime harcanan süre toplam 100 milisaniye, yani 0,1 saniyedir. İki uçtaki işleme süreleri bu örneğe dahil edilmemiştir.

flowchart TB
    accTitle: Tek bir karakterin sonucu dönene kadar geçen iletişim süresi örneği
    accDescr: Açıklama amacıyla gidiş ve dönüşün her birini 50 milisaniye varsayan bir örnektir. İki uçtaki işleme süresini içermez ve tuş başına paket sayısını da göstermez.
    A["Yerelde bir karakter yazılır"] -->|"Gidiş: 50 ms"| B["Uzak taraf girdiyi alır"]
    B --> C["Girdiyi yansıtan ekran gönderilir"]
    C -->|"Dönüş: 50 ms"| D["Sonuç yerele ulaşır"]

Şekil 3: Gidiş 50 milisaniye, dönüş 50 milisaniye varsayılırsa yalnızca iletişim 0,1 saniye sürer. Bunlar ölçülmüş değerler değildir.

Bağlantının taşıyabildiği miktar artsa bile gidiş-dönüş süresi değişmezse bu 0,1 saniye kalır. Şekil 3, işleyişi anlamak için çizilmiş kavramsal bir şekildir. Her tuş için bağımsız bir gidiş-dönüşlük paket gönderildiği anlamına gelmez. Hız testinin karşı tarafına giden yol ile RDP’nin bağlandığı bilgisayara giden yol da farklıdır; VPN’i, ağ geçidini, uzak taraftaki yukarı yönlü hattı ve aradaki tıkanıklığı da hesaba katarak düşünün. Bkz. RTT’nin nasıl ele alınacağı, ağ ve ana bilgisayar performansı.

Ekranın oluşturulması ve iletilmesi

Burada işlem yanıtındaki gecikme, yerelde bir işlem yaptıktan sonra sonucu görene kadar geçen beklemedir. Yalnızca RTT değil, uygulamanın işlemesi ile ekranı oluşturup ulaştırma işlemesi de etkilidir. Bunu yalnızca ekranın aktarıldığı aralıktaki gecikmeden de ayırıyoruz. Bkz. ekranın yakalanmasından görüntülenmesine kadar ölçülen aralık.

Girdi yerel bilgisayardan uzak bilgisayara ulaştığında uzak bilgisayardaki uygulama girdiyi işleyip ekranı günceller, kodlanmış ekran bilgisi bağlantı üzerinden taşınır ve yerel bilgisayarda kodu çözülüp görüntülenir. İletişimin öncesinde ve sonrasında da ayrı bilgisayarların üstlendiği işler vardır. Bkz. ekranın yakalanmasından görüntülenmesine kadarki işleme.

flowchart TB
    accTitle: Bağlantının öncesinde ve sonrasında da ekran işleme vardır
    accDescr: Yereldeki girdinin uzak bilgisayara ulaşması, uzak bilgisayardaki uygulamanın onu işleyip ekranı oluşturması ve sıkıştırması, bağlantı üzerinden taşınan ekran bilgisinin yerelde görüntülenebilir biçime geri dönüştürülüp gösterilmesine kadarki akış.
    I["Yerel: işlem girilir"] --> J["Bağlantı: girdiyi taşır"]
    J --> K["Uzak: uygulama işler"]
    K --> A["Uzak: ekranı oluşturup sıkıştırır"]
    A --> B["Bağlantı: ekran bilgisini taşır"]
    B --> C["Yerel: görüntülenebilir biçime çevirir"]
    C --> D["Yerel ekranda gösterilir"]

Şekil 4: Uzak tarafta işleyip sıkıştırma, bağlantıyla taşıma ve yerelde görüntülemeye geri çevirme. Her biri ayrı bir yerde yapılan iştir.

Bu makalede kodlama, uzak bilgisayarda ekranı gönderilmesi kolay bir biçime dönüştürme ve sıkıştırma işlemesidir. Bağlantı üzerinden aktarımdan ayrı olarak uzak bilgisayarda işleme süresi gerektirir. Bkz. uzak bilgisayardaki kodlama süresi.

Bu makalede kod çözme, gelen ekran bilgisini yerel bilgisayarda görüntülenebilir biçime geri dönüştürme işlemesidir. Bunu, şifrelemeyi kaldırmak anlamındaki şifre çözmeden ayırıyoruz. Bkz. yerelde kod çözme ve görüntüleme süresi.

Uzak bilgisayarda sıkıştırma zaman alırsa bağlantı boş olsa bile gönderim hazırlığı beklenir. Bilgi ulaşmış olsa bile yerelde kod çözme veya görüntüleme yetişemezse güncelleme gecikir. “Şirketteki bilgisayar güçlü, yerel cihaz ne olsa olur” düşüncesi her zaman geçerli değildir. Bağlantıdaki pay ile bağlantının iki ucundaki işleme payı ayrı şeylerdir. Bkz. ekran işlemenin performans sayaçları.

flowchart TB
    accTitle: İki uçtaki işleme yetişemediğinde oluşan gecikme
    accDescr: Uzak taraftaki sıkıştırma zaman alırsa bağlantı boş olsa bile gönderim hazırlığının beklendiğini, yereldeki kod çözme veya görüntüleme yetişemezse bilgi ulaşmış olsa bile güncellemenin geciktiğini gösterir.
    A["Uzak sıkıştırma zaman alır"] --> B["Bağlantı boşken gönderim bekler"]
    B ~~~ C["Yerel kod çözme yetişemez"]
    C --> D["Ulaşsa da güncelleme gecikir"]

Şekil 5: Bağlantıda pay olsa bile iki uçtaki işleme yetişemezse ekran güncellemesi gecikir.

Yazı yazma ile kaydırma arasındaki fark

Not Defteri’ne tek bir karakter eklediğinizde ekranın yalnızca küçük bir kısmı değişir. Fotoğraf dolu bir sayfayı kaydırdığınızda ise geniş bir alanın görüntüsü art arda değişir. RDP, değişen kısımları aktararak ve içeriğe uygun sıkıştırma ve önbellekleme kullanarak iletişim miktarını azaltır. Her seferinde ekranın tamamını sıkıştırmadan göndermez. İş miktarı, ekranın içeriğine ve güncelleme sıklığına göre değişir. Bkz. ekran içeriği ile bant genişliği arasındaki ilişki.

flowchart TB
    accTitle: Yazı yazma ve kaydırmada değişen ekran iş miktarı
    accDescr: Küçük bir karakter değişikliği ile geniş bir alanın sürekli güncellenmesi, ekranı oluşturup gönderme işinin niteliği bakımından farklıdır.
    A{"Ekrandaki değişiklik"} -->|"Bir karakter eklenir"| B["Küçük alan"]
    A -->|"Kaydırma"| D["Geniş alan sürekli"]
    B --> E["Değişikliğe göre sıkıştır ve aktar"]
    D --> E

Şekil 6: Aynı bağlantıda bile bir karakter eklemek ile geniş bir alanın sürekli hareket ettiği durumlar arasında iş miktarı değişir.

Duran bir belge hafif olsa bile kaydırma sırasında ekran aktarımında pay kalmayabilir. Uzak taraftaki çözünürlüğü veya monitör sayısını artırmak işlenecek ekranı da büyütür. Çözünürlüğü düşürerek yapılan karşılaştırma, ekranı oluşturup gönderme işi azaltıldığında hareketin düzelip düzelmediğine bakan bir deneydir. İletişim miktarını yalnızca piksel sayısından belirleyen bir hesap değildir. Bkz. çözünürlüğün, ekran güncellemelerinin ve sıkıştırmanın etkisi.

Uygulama beklemeleri

Yalnızca iş uygulamasındaki arama birkaç saniye donuyor ve aynı oturumdaki Not Defteri’ne normal yazabiliyorsanız o uygulamanın ne beklediğini kontrol edin. Uzak bilgisayardaki uygulama başka bir veritabanına sorgu gönderiyor ya da paylaşılan bir klasörden dosya okuyor ve bunun yanıtını bekliyor olabilir. Bu, yerel bilgisayar ile uzak bilgisayarı bağlayan RDP iletişiminden ayrı bir yoldur. Bkz. uzak bilgisayardan arka uca iletişim.

flowchart TB
    accTitle: RDP'nin ötesinde de iletişim kurulan taraflar vardır
    accDescr: Yerel cihaz ile uzak bilgisayar arasındaki iletişimden ayrı olarak uzak bilgisayardaki uygulamanın bir iş sunucusunun yanıtını beklediği durumu gösterir.
    A["Yerel cihaz"] -->|"RDP"| B["Uzaktaki iş uygulaması"]
    B -->|"Sorgu/dosya isteği"| C["Veritabanı/paylaşılan klasör"]
    C -->|"Beklenen yanıt"| B

Şekil 7: RDP’nin ötesindeki iş uygulaması, bir başka sunucunun yanıtını bekliyor olabilir.

Ekrandan ve girdiden sorumlu işleme uzun bir işle meşgul olursa sonraki girdi ve ekran güncellemesi gecikir. Örneğin WPF’te UI iş parçacığı uzun süre meşgul kalırsa yanıt verebilirlik bozulur. Yalnızca CPU’nun genel kullanımının düşük olmasına bakarak belirli bir UI iş parçacığındaki beklemeyi dışlayamazsınız. Bkz. Dispatcher ve UI iş parçacığı.

flowchart TB
    accTitle: Ekrandan ve girdiden sorumlu işleme tıkanır
    accDescr: Ekrandan ve girdiden sorumlu işleme uzun bir işle meşgul olursa sonraki girdi ve ekran güncellemesinin geciktiğini, CPU'nun genel kullanımının düşük olmasının tek başına bu beklemeyi dışlayamadığını gösterir.
    A["Ekran ve girdiden sorumlu işleme"] --> B["Uzun bir işle meşgul olur"]
    B --> C["Sonraki girdi ve güncelleme gecikir"]
    C -.- D["Genel CPU düşük olsa da dışlanamaz"]

Şekil 8: UI iş parçacığındaki bekleme yalnızca CPU’nun genel kullanımına bakarak dışlanamaz.

Belirtiye göre ilk karşılaştırma

Taşınabilen miktar, yanıt için beklenen süre ve ekranı oluşturup görüntüleme süresi ayrı şeylerdir. Bu ayrımı korursanız “RDP yavaş” durumunu tek bir nedene bağlayıp geçmeden, şu anda yavaş olan işlemden başlayarak inceleyebilirsiniz.

flowchart TB
    accTitle: Üçünü ayırdıktan sonra incelemek
    accDescr: “RDP yavaş” durumunu tek bir nedene bağlamadan taşınabilen miktarı, yanıt için beklenen süreyi ve ekranı oluşturup görüntüleme süresini ayırarak şu anda yavaş olan işlemden başlayıp incelemeyi gösterir.
    A["“RDP yavaş”"] --> S
    subgraph S["Ayrı ayrı bakmak"]
    direction TB
    B["Taşınabilen miktar"] ~~~ C["Yanıt bekleme süresi"]
    C ~~~ D["Ekranı oluşturup gösterme süresi"]
    end
    S --> E["Şu an yavaş olan işlemden incele"]

Şekil 9: Taşınabilen miktarı, yanıt bekleme süresini ve ekranı oluşturup görüntüleme süresini ayırırsanız şu anda yavaş olan işlemden başlayarak inceleyebilirsiniz.

Ayrıştırmada amaç, yavaşlığın inceleneceği yeri sınırlamaktır. Ayarları topluca değiştirip tesadüfen hızlandırmak amaç değildir. “Not Defteri çalışıyor ama yalnızca arama donuyor”, “yazı yazmak normal ama yalnızca kaydırma ağır” gibi farkları kullanırsanız iletişim ayarlarını değiştirmeden önce de incelemeye nereden başlayacağınızı seçebilirsiniz.

Aşağıdaki tablo incelemenin başlangıç noktasıdır. Nedeni belirleyen bir tablo değildir. İşlemleri aynı oturumda karşılaştırdıktan sonra gereken cihazı, yolu veya görüntüleme koşullarını değiştirin.

Birden çok uygulamada karakterler gecikiyor

Aynı oturumdaki birden çok uygulamada karakterler birer birer gecikiyorsa aynı işlemi başka bir cihazdan veya izin verilmiş başka bir yoldan da karşılaştırın. Gidiş-dönüş süresini, uzak bilgisayardaki girdi beklemesini ve uzak bilgisayarın genel yükünü birbiriyle eşleştirin; nedeni tek bir sayıya bakarak belirlemeyin.

Yalnızca kaydırma takılıyor

Yazı yazmak normal olsa bile fotoğraf dolu bir sayfayı kaydırınca geniş bir alanda ekran güncellemeleri sürer. Uzak taraftaki çözünürlüğü veya monitör sayısını birer birer değiştirip aynı sayfada karşılaştırın. İyileşme olursa bir sonraki inceleme hedefleri uzak bilgisayardaki sıkıştırma, ekran aktarımı ve yerelde kod çözmedir. Yalnızca çözünürlüğe bakarak bu üçünden hangisinin neden olduğu anlaşılmaz. Bkz. ekran içeriği ve çözünürlüğe bağlı yük.

Yalnızca tek bir uygulama donuyor

Yalnızca aramaya bastığınız iş uygulaması donuyorsa aynı oturumdaki Not Defteri gibi uygulamaların yanıt verip vermediğini karşılaştırın. Diğer uygulamalar çalışıyorsa önce hedef uygulamanın işlemesini, diski ve veritabanına ya da paylaşılan klasöre giden istekleri inceleyin. RDP üzerinden çalışıyor olmak ile beklemenin nedeninin RDP iletişimi olması ayrı şeylerdir. Bkz. uygulama ve arka ucun performans etkenleri.

Yalnızca kullanıcıların arttığı saatlerde herkes yavaş

Aynı saatlerde birden çok kullanıcıda yavaşlık oluyorsa diğer oturumların durumunu yöneticiye sorun. Paylaşılan ana bilgisayarın CPU, bellek ve depolama yükünü ve paylaşılan hattın yükünü belirtinin görüldüğü saatle eşleştirin. Diğer kullanıcıların kayıtlarına ve işlemelerine izinsiz erişmeyin, işlerini durdurmayın. Bkz. paylaşılan ana bilgisayarın kaynakları ve kullanıcı sayısı.

Kopyalama veya yazdırma sırasında yavaşlıyor

Kendi kopyalama veya yazdırma işinizi başlattığınız an ile sorun çakışıyorsa yalnızca durdurulmasına izin verilen aktarımları geçici olarak duraklatıp karşılaştırın. Duraklattıktan sonra düzelip düzelmediğini, yeniden başlatınca yavaşlayıp yavaşlamadığını kaydedin ve ekran dışı aktarımlarla veya cihaz yeniden yönlendirmesiyle çakışmayı inceleyin. İş için gerekli cihazları topluca devre dışı bırakarak karşılaştırma yapmayın. Bkz. cihaz yeniden yönlendirmesinin etkisi.

Koşulları tek tek karşılaştırma

Tüm ayarları sırayla değiştirmeniz gerekmez. Önce karşılaştırma için bir temel oluşturun ve yalnızca belirtiye uyan kontrolleri seçin. Ayarları değiştirmeden veya yeniden bağlanmadan önce çalışmanızı kaydedin; özgün değerleri ve nasıl geri alınacağını not edin. Gereken izinler veya özellikler yoksa zorla etkinleştirmeyin; konuyu yöneticiye devredin.

Yerel işlem ile RDP üzerinden işlem her zaman aynı koşullarda değildir. Uzak bilgisayarın fiziksel ekranında hızlı olması bir fikir verir, ancak oturum ve çizim koşulları değişebilir. Kullanıcıyı, veriyi ve uygulamanın durumunu eşitleyin; yalnızca “fiziksel ekranda hızlı” diye nedeni bağlantıyla sınırlamayın.

Aynı işlemi karşılaştırma

Aynı kullanıcıyı, aynı veriyi ve aynı işlemi hazırlayın. Paylaşılan ana bilgisayarlarda kendi oturumunuzu doğrulayın; diğer kullanıcıların uygulamalarını veya işlemelerini durdurmayın. Başka bir cihaz veya başka bir yol kullanmak da yöneticinin izin verdiği kapsamla sınırlıdır.

1. Özgün ayarlarla yavaş işlemi yeniden üretin; saati ve belirtiyi kaydedin.

   Sorunlu uygulamayla aynı uzak oturumdaki Not Defteri’ne benzer miktarda yazı yazın. Sorunun yalnızca tek bir uygulamada mı yoksa oturumun tamamında mı olduğunu ayırt edin.

2. Uzak bilgisayarın ve yerel bilgisayarın yükünü aynı zaman diliminde kontrol edin.

   Görev Yöneticisi’nde uzak bilgisayarda hedef uygulamanın CPU, bellek ve disk kullanımına, yerel bilgisayarda ise RDP istemcisinin yüküne bakın. Yalnızca genel CPU değerine değil, hedef sürece de bakın. Bkz. yük incelemesinde bakılacak hedefler.

3. Başka bir cihaz, izin verilmiş başka bir yol ve görüntüleme koşulları arasından yalnızca bir koşulu değiştirip aynı işlemi tekrarlayın.

   Uzak bilgisayarın veya uygulamanın durumunun da aynı anda değiştiği karşılaştırmalarda bu farkı da kaydedin. Birden çok koşulun değiştiği bir sonucu tek bir koşulun etkisi saymayın.

4. Özgün koşullara dönün ve aynı işlemi yeniden kontrol edin.

   Geri döndükten sonra da hızlı kalıyorsa geçici bir yük değişimi gibi olasılıklar da düşünülebilir. Değişikliğin işe yaradığına hemen hükmetmeyin; belirtinin yeniden üretildiği koşulları kaydedin.

Özgün durumun, değişiklik sonrasının ve geri alınmış durumun sonuçları bir araya gelince hangi koşulun belirtiyle örtüştüğünü karşılaştırabilirsiniz. İyileşme sağlayan bir koşul incelemede bir ipucudur; tek başına kök nedenin kanıtı olmaz.

flowchart TB
    accTitle: Bir seferde değiştirilen koşulu sınırlamak
    accDescr: Özgün durumda yeniden üretilen işlemi belirleyip yalnızca tek bir koşulu değiştirerek karşılaştırma yapan ve geri alınca elde edilen sonucu da kontrol eden akış.
    A["Özgün ayarla aynı işlem"] --> B["Yalnızca bir koşulu değiştir"]
    B --> C["Aynı işlemi tekrarla"]
    C --> D["Geri al ve yeniden kontrol et"]
    D --> E["İyileşen koşulu kaydet"]

Şekil 10: Özgün durumda, değişiklikten sonra ve geri alınmış durumda aynı işlemi tekrarlayın ve değişen koşulu kaydedin.

Uzak taraftaki çözünürlüğü karşılaştırma

Kaydırma gibi ekran güncellemelerinin ağır olduğu durumlarda karşılaştırın. Değişiklikten önceki çözünürlüğü ve monitör sayısını kaydedin, çalışmanızı kaydedip yeniden bağlanın. İş için gerekli ekranları veya yazının okunabilirliğini bozan ayarları olduğu gibi sürekli kullanmayız.

1. Monitör sayısından veya çözünürlükten yalnızca birini değiştirin.

   mstsc uygulamasında bağlanmadan önce “Görüntü” sekmesindeki ayarlarla veya genişlik ve yükseklik belirterek karşılaştırabilirsiniz. Bkz. mstsc ile ekran belirtme.

2. Uzak masaüstünün gerçek boyutunun değiştiğini doğrulayın ve aynı sayfayı kaydırın.

   Yalnızca yerel pencereyi küçültmek, büyük bir masaüstünün küçültülerek gösterilmesiyle sonuçlanabilir. Dinamik çözünürlük ile smart sizing’i ayırt edin ve kullandığınız istemcinin destek koşullarını kontrol edin. Bkz. masaüstü çözünürlüğü ve görüntüleme ölçeği.

3. Özgün ayara dönüp aynı işlemi tekrarlayın; iki uçtaki yükü ve ekranın hareketini karşılaştırın.

   Düşük çözünürlüğe ve tek monitöre aynı anda geçtiyseniz karşılaştırma kaba bir karşılaştırma olarak kalır. İyileşme olursa birer birer geri alıp etkileri ayırın.

İyileşme olursa ipucu ekran işleme ve ekran aktarımı kapsamındadır. 3840×2160 çözünürlük, 1920×1080’in dört katı piksel içerir, ancak iletişim miktarı her zaman dört kat olmaz. Değişen kısımlara ve sıkıştırmaya göre değişir; çözünürlük değişikliği iki uçtaki işlemeyi de etkiler. Bkz. piksel sayısı ile iletişim miktarı arasındaki ilişki, ekran işlemenin kontrolü.

flowchart TB
    accTitle: Çözünürlüğü düşüren karşılaştırmanın gösterdiği kapsam
    accDescr: Uzak taraftaki çözünürlüğü düşürmek hem ekran işlemenin hem aktarımın yükünü değiştirebileceğinden, yalnızca iyileşmeye bakarak neden bağlantıyla sınırlanamaz.
    A["Uzak çözünürlüğü düşür"] --> S
    subgraph S["Değişen işlemeler"]
    direction TB
    B["Uzaktaki ekran işleme"] ~~~ C["Gönderilen bilgi miktarı"]
    C ~~~ D["Yereldeki görüntüleme işlemesi"]
    end

Şekil 11: Çözünürlük değişikliği yalnızca bağlantıyı değil, uzak ve yerel bilgisayardaki ekran işlemeyi de etkileyen bir karşılaştırmadır.

Kopyalama ve yazdırmayı belirtiyle eşleştirme

Yalnızca kendi başlattığınız aktarımlar gibi durdurulmasına izin verilen işlemeler geçici olarak duraklatılır. Şirketin yedekleme ve güvenlik işlemelerini veya diğer kullanıcıların işlerini durdurmayın. İş için gerekli ses ve girdi cihazlarının yeniden yönlendirmesini topluca devre dışı bırakmayın.

1. Kopyalama, bulut eşitleme veya yazdırma başlamadan önce ve sürerken aynı işlemi ve yükü kaydedin.

   RDP’de ekranın dışında sürücüler ve yazıcılar gibi bilgiler de akar. Yerel cihazları uzak bilgisayarda kullanmayı sağlayan yeniden yönlendirme, kullanıldığı sırada iletişim ve işleme yükünü artırabilir. Bkz. cihaz yeniden yönlendirmesinin etkisi.

2. Hedef aktarımı izin verilen kapsamda geçici olarak duraklatın ve aynı işlemi yeniden kontrol edin.

   Devam ettirip karşılaştırabiliyorsanız devam ettirdikten sonraki belirtiyi de kaydedin. Gereksiz cihaz yeniden yönlendirmelerini denerken de birer birer değiştirin ve özgün ayara geri dönebilecek durumda olun.

Aktarımın başlamasının sorunla, duraklatmanın da düzelmeyle örtüşüp örtüşmediğine karar verebilirsiniz. Bir örtüşme görülürse ekran dışı aktarımları ve paylaşılan kaynakların yükünü yöneticinin kayıtlarıyla eşleştirin.

flowchart TB
    accTitle: Sorunun öncesini ve sonrasını aynı zaman ekseninde görmek
    accDescr: Aktarım öncesinde, sırasında ve duraklatıldıktan sonra aynı işlemi ve yükü kaydedip sorun ile yapılan iş arasındaki ilişkiyi karşılaştırır.
    A["Aktarım öncesi işlem ve yük"] --> B["Aktarım sırasında işlem ve yük"]
    B --> C["Duraklatma sonrası işlem ve yük"]
    C --> D["Sorun ve düzelme örtüşüyor mu"]

Şekil 12: Aktarım öncesinde, sırasında ve duraklatıldıktan sonra aynı işlemin yavaşlığının ve yükün nasıl değiştiğine bakın.

Beklemenin yerini ölçme

Yerel bilgisayardan iletişimin gidiş-dönüşünü ve TCP bağlantısını, uzak bilgisayarda ise girdi kuyruğundaki beklemeyi ve ekran güncellemelerini inceleyin. Her sayının ölçtüğü aralık sınırlı olduğundan sonuçları “Ölçüm sonuçlarının kapsamı” bölümündeki tabloyla karşılaştırarak okuyun.

ICMP ve TCP bağlantısını kontrol etme

Çalıştırılacağı yer yerel Windows cihazıdır. Yalnızca şirket LAN’ı veya izin verilmiş bir VPN üzerinden, standart TCP 3389’u kullanan bir RDP ana bilgisayarına doğrudan bağlanılan yapılar kapsamdadır. RD Gateway veya Azure Virtual Desktop üzerinden ya da özel bağlantı noktası kullanan yapılarda neyin kontrol edileceğini yöneticiyle birlikte belirleyin. Bağlantı noktalarını dışa açmayız ve güvenlik duvarını değiştirmeyiz.

1. İzin verilen bağlantı hedefini girin ve ICMP yanıtı ile TCP bağlantısının sonuçlarını kaydedin.

   $target = Read-Host 'İncelenmesine izin verilen RDP ana bilgisayarının adı veya IP adresi'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'Bağlantı hedefini belirtin.'
   }
       
   # ICMP yanıt süresine birkaç kez bakın. Başarısızlık tek başına RDP bağlantısının olmadığını göstermez.
   ping.exe -n 20 $target
       
   # Yalnızca standart TCP 3389 bağlantı noktasına doğrudan bağlanılan yapılar için kontrol.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. Yavaş saatlerdeki ve normal zamandaki sonuçları belirtinin görüldüğü saatle ve gerçek bağlantı yoluyla eşleştirin.

   20 kez yapılan ping kısa bir gözlemdir. Değerlerdeki dalgalanmayı ve yanıt gelmemesini kaydedin, ancak ICMP’nin engellendiği durumlar da vardır. Aralıklı kesintileri yalnızca ortalamaya bakarak dışlamayın; bağlantı bilgilerini ve yöneticinin iletişim kayıtlarını kullanın. Bkz. ping’in ölçtüğü şey.

TcpTestSucceeded: True, belirtilen bağlantı noktasına TCP bağlantısının başarılı olduğu anlamına gelir. Bant genişliğini, UDP’yi, kimlik doğrulamadan sonraki işlemleri ve ekranın akıcılığını ölçmez. Test-NetConnection komutunda UDP’yi inceleyen bir -UDP anahtarı yoktur. Bkz. Test-NetConnection sözdizimi ve sonuçları.

Yol ve hizmet farklarını göz ardı etmeden değerlendirin. RD Gateway gibi yapılarda ana bilgisayara giden ICMP’nin veya doğrudan TCP bağlantısının yolu ile gerçek RDP yolu örtüşmeyebilir. Azure Virtual Desktop’ta bağlantı başına RTT’yi ve bant genişliği tahminini kullanabilirsiniz, ancak bu tanılama özelliği o hizmete özgüdür. Kısa kesintileri yalnızca ortalamaya bakarak dışlamayız. Bkz. Azure Virtual Desktop bağlantı kalitesi günlükleri.

flowchart TB
    accTitle: Kontrol edilen yol ve gerçek RDP yolu
    accDescr: RD Gateway gibi bileşenlerin kullanıldığı yapılarda yerelden ana bilgisayara giden ICMP veya doğrudan TCP bağlantısının yolu ile gerçek RDP yolu örtüşmeyebilir.
    A["Yerel cihaz"] -->|"ICMP/doğrudan TCP"| C["RDP ana bilgisayarı"]
    A -->|"Gerçek RDP"| B["RD Gateway vb."]
    B --> C

Şekil 13: Ana bilgisayara giden ICMP veya doğrudan TCP bağlantısı ile gerçek RDP’nin yolu örtüşmeyebilir.

Girdi kuyruğundaki beklemeyi ölçme

User Input Delay, uzak bilgisayarda girdinin kuyruğa girmesinden sürecin onu almasına kadar geçen beklemeyi ölçer. Bir tuşa basıp karakteri görene kadar geçen toplam süre değildir. Bkz. User Input Delay tanımı.

İnceleme, uzak bilgisayardaki uzak oturumun içinde yapılır. Microsoft’un destek koşulları Windows 10 sürüm 1809 ve sonrası ile Windows Server 2019 ve sonrasıdır. Bu sistemlerde etkinleştirme için kayıt defterine ekleme yapmak gerekmez. Görünen adları, izinleri ve sayaçların var olup olmadığını kontrol edin; kullanılamıyorsa bu durumu kaydedip yöneticiye danışın. Bkz. destek koşulları ve ayarlar.

1. Aynı oturumdaki PowerShell’de saati ve oturum kimliğini not edin.

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

   Diğer kullanıcıların oturumlarını sorgulamak için ek izinler gerekebilir. Hedef sürecin standart örnek adı SessionID:ProcessID <Process Image> biçimindedir. Yalnızca oturum kimliğine bakarak başka kullanıcıların veya aynı adlı süreçlerin değerlerini karıştırmayın. Bkz. query session izinleri, örneğin tanımlanması.

2. perfmon.exe içinde, kullanılabilen User Input Delay per Process veya User Input Delay per Session sayacını ekleyin.

   Hedef süreci veya oturumu seçin ve başlangıçta varsayılan 1 saniyelik aralıkla gözlemleyin. Birden çok oturumu bir araya getiren toplu örnek ile tek tek oturumların değerlerini ayırt edin.

3. Girdinin yavaş olduğu işlemi yeniden üretin ve kuyruktaki beklemeyi belirtinin görüldüğü saatle karşılaştırın.

   Tek tek ölçüm hedeflerinde bakılan değer, ölçüm aralığındaki en uzun bekleme süresidir. Değer düşük olsa bile uygulamanın girdiyi aldıktan sonraki işlemesi ve sonucun yerel bilgisayara dönmesine kadar geçen gecikme kalır.

Uzak bilgisayardaki girdi kuyruğunda bekleme olup olmadığını inceleyebilirsiniz. Bu, iletişimin gidiş-dönüşünü ve yerelde görüntülemeyi de içeren algılanan süreden farklı bir göstergedir. Bkz. en büyük değerin ve ölçüm aralığının anlamı.

flowchart TB
    accTitle: User Input Delay sayacının ölçtüğü aralık
    accDescr: Ölçülen aralık uzak bilgisayardaki girdi kuyruğundan uygulamanın girdiyi almasına kadardır; öncesindeki ve sonrasındaki iletişim ile ekran görüntüleme dahil değildir.
    A["Girdi yerelden ulaşır"] --> B["Uzaktaki girdi kuyruğuna girer"]
    B -->|"Burası ölçülür"| C["Uygulama girdiyi alır"]
    C --> D["Uygulama işlemesi ve ekran aktarımı"]
    D --> E["Yerelde görüntülenir"]

Şekil 14: Ölçülen, uzak bilgisayardaki girdi kuyruğunda geçen beklemedir. Sonucun yerelde görünmesine kadar geçen toplam süreden farklıdır.

Ekran güncellemelerini ve kare atlama nedenlerini inceleme

Kaydırma gibi ekran güncellemelerinin sürdüğü bir işlem hazırlayın. RemoteFX Graphics sayaçlarının kullanılabilirliği ve ölçüm yeri işletim sistemine, ana bilgisayar yapısına ve izinlere göre kontrol edilmelidir. Burada yalnızca kullanılabilen sayaçlar okunur. Eski RemoteFX özelliğini kurma veya etkinleştirme adımları değildir. Bkz. Graphics sayaçlarının geçerlilik koşulları.

1. query session veya qwinsta ile hedef oturumun adını doğrulayın ve karşılık gelen sayaç örneğini seçin.

2. Ekran güncellemesi olan bir işlem sırasında Input Frames/Second ile Output Frames/Second değerlerini karşılaştırın.

   Çıkış girişten azsa ekran kareleri yolda atlanıyordur. Frames Skipped/Second sayacının uzak bilgisayar, ağ ve istemci kaynak yetersizliğine göre ayrılmış değerlerini kontrol edin.

3. Kare atlama nedenlerini iki uçtaki ve iletişimdeki yükle eşleştirin; Average Encoding Time değerini de kontrol edin.

   Kodlama süresi uzunsa uzak bilgisayardaki sıkıştırma işlemesini inceleyin. Kare sayısı daha giriş tarafında düşükse uygulamanın ekranı sık güncellemiyor olması da mümkündür. Duran bir ekranda kare sayısının düşük olması tek başına bir anormallik değildir.

Ekran güncellemesi sırasındaki giriş ve çıkış karelerinden, kare atlama nedenlerinden ve kodlama süresinden incelenecek yeri daraltabilirsiniz. Sayaçların sınıflandırması bir ipucudur; gerçek yük ve bağlantı yapısıyla birlikte değerlendirin. Bkz. kare sayısının ve kodlama süresinin okunması.

flowchart TB
    accTitle: Ekran karelerinin atlanmasından incelenecek yeri daraltmak
    accDescr: Ekran güncellemesi olan bir işlem sırasında giriş ve çıkış kare sayılarını karşılaştırır, kare atlama nedeni sayaçlarını ipucu olarak kullanıp işleme, iletişim ve görüntüleme yüküyle eşleştirir.
    A["Kaydırırken giriş/çıkışı karşılaştır"] --> B["Çıkış azsa atlamayı kontrol et"]
    B --> C["Nedene göre sayaçlara bak"]
    C --> D["Uzak/iletişim/yerel yükle eşleştir"]

Şekil 15: Kaydırma sırasındaki giriş ve çıkışı karşılaştırın; kare atlama nedenlerini uzak bilgisayardaki, hattaki ve yerel bilgisayardaki yükle eşleştirin.

Ekran aktarımının kavramsal şeklini veya eski belgeleri tüm yapılara genellemeyiz. Video ve sesi ayrı bir mekanizmayla aktaran yapılar da vardır. Graphics sayaçlarının belgeleri eski yapıların açıklamalarını da içerdiğinden, oradaki sayıları “tüm RDP’ler en fazla 30 fps” şeklinde ortak bir belirtim olarak yorumlamayız. Özelliklerin ve sayıların neye uygulandığını kontrol ederek kullanın. Bkz. ekran aktarımı ve iş yükleri, Graphics sayaçları belgesi.

Ölçüm sonuçlarının kapsamı

Sayının düşük olması ile işlemin rahat olmasını bir tutmayız. Her göstergenin kapsamını adımlarda belirtilen Microsoft belgelerinden kontrol edebilirsiniz.

İletişim ve GPU ayarları

UDP ve GPU ayarları, karşılaştırma ve ölçümlerle anlaşılanlara göre seçilir. İletişimden şüpheleniliyorsa önce bağlantı yöntemini ve yolu, ekran işlemeden şüpheleniliyorsa önce GPU’nun hangi aşamada kullanıldığını kontrol edin.

TCP/UDP ve bağlantı yolunu kontrol etme

Karşılaştırma ve ölçümler iletişimi şüpheli gösteriyorsa kullanılan istemciyi, yolu ve uygulanan ilkeleri yöneticiyle birlikte kontrol edin. Ayar değişikliği gerekse bile onaylanan kapsamla sınırlı kalın; değişiklik öncesi değerleri ve geri dönüş yöntemini kaydedin. Güvenlik duvarını veya kimlik doğrulamayı devre dışı bırakmayız, RDP bağlantı noktasını da doğrudan internete açmayız.

1. Bağlantı bilgileri, ürünün tanılama günlükleri ve yöneticinin iletişim kayıtlarıyla gerçek TCP/UDP kullanımını ve yolu doğrulayın.

   RDP, yapılandırmaya ve iletişim koşullarına göre TCP veya UDP kullanır. “Select RDP transport protocols” ilkesinde UDP veya TCP kullanan ayar ile yalnızca TCP kullanan ayar arasında seçim yapılabilir. UDP bağlantısı kurulamazsa TCP kullanan bir davranış da olduğundan, yalnızca bağlantının başarılı olmasından yöntem anlaşılmaz. Bkz. RDP transport seçimi ve geri dönüş.

2. Yolu ve yöntemi belirtinin görüldüğü saatle eşleştirin; yalnızca gerekli ayarları birer birer karşılaştırın.

   “UDP’yi kapatırsak hızlanır” diyerek genel bir değişiklik yapmayız. VPN ve ağ geçidi koşullarını, işlemi ve görüntüleme koşullarını eşitleyerek karşılaştırın; gereksiz değişiklikleri geri alın.

Yöntemi ve yolu öğrendikten sonra değişiklik ile belirti arasındaki ilişkiyi kaydedebilirsiniz. Yalnızca TCP’ye geçmek her zaman hızlanma sağlamaz.

flowchart TB
    accTitle: Bağlantı yöntemini kontrol ettikten sonra iletişim ayarlarını karşılaştırmak
    accDescr: Normal doğrudan bağlantıyı ağ geçidi veya hizmet üzerinden bağlantıdan ayırır, gerçek yolu ve yöntemi kontrol ettikten sonra izin verilen karşılaştırmaları yapar.
    A["Kullanılan istemci ve bağlantı yapısı"] --> B["Gerçek yolu ve TCP/UDP'yi doğrula"]
    B --> C["Belirti saatiyle eşleştir"]
    C --> D["Yalnızca gerekeni birer birer karşılaştır"]

Şekil 16: Kullanılan bağlantı yöntemini ve yolu doğrulayın, belirtiyle eşleştirin, ardından yalnızca gerekli ayarları karşılaştırın.

RDP Shortpath, Azure Virtual Desktop’a ait bir mekanizmadır. Bu hizmetin UDP yolunu kurar ve yapılandırmaya göre doğrudan bir yol veya aktarma kullanır. Kurulamazsa TCP tabanlı bağlantıya geri döner. Şirket bilgisayarına doğrudan mstsc ile bağlanma durumuyla aynı ayar tablosunda ele alınamaz. Bkz. RDP Shortpath yolları ve geri dönüş.

flowchart TB
    accTitle: RDP Shortpath yolları ve geri dönüş
    accDescr: Azure Virtual Desktop'taki RDP Shortpath, UDP yolu kurmayı dener; kurulursa yapılandırmaya göre doğrudan yol veya aktarma kullanır, kurulamazsa TCP tabanlı bağlantıya geri döner.
    A["RDP Shortpath"] --> B{"UDP yolu"}
    B -->|"Kuruldu"| C["Doğrudan veya aktarma"]
    B -->|"Kurulamadı"| D["TCP tabanlıya dön"]

Şekil 17: RDP Shortpath, UDP yolunu kuramazsa TCP tabanlı bağlantıya geri döner.

Ekran işlemede GPU kullanımını kontrol etme

Karşılaştırma ve ölçümler ekran işlemeyi şüpheli gösteriyorsa kontrol edin. Ekran işlemenin ölçüm sonuçlarını ve desteklenen işletim sistemini, sürücüyü, ilkeleri ve istemciyi kontrol edin. Yalnızca GPU takılı olduğu için ayar değiştirmeyiz. Önce yöneticinin onayını alın ve eski hâline döndürmeye hazırlanın.

1. Uzak bilgisayardaki uygulamanın çizimini, RDP kodlamasını ve yerelde kod çözmeyi ayırın; şüpheli aşamayı seçin.

   GPU olsa bile tüm aşamaların GPU’yu kullandığı kesin değildir. Microsoft’un Azure Virtual Desktop için yapılandırma belgelerinde de uzak oturumun çizimi ile karelerin donanımla kodlanması ayrı ayrı yapılandırılır ve kontrol edilir. Bkz. çizim ve kodlama için GPU yapılandırması ve doğrulaması.

2. Hedef ürünün adımlarına göre gerçek kullanım durumunu kontrol edin ve gerekli değişiklikten önce ve sonra aynı işlemi ölçün.

   Sıkıştırma süresi uzunsa kodlamada GPU kullanımını inceleyin. Girdi kuyruğunda bekleyen bir uygulama için kodlama ayarlarını değiştirmek yanlış yeri hedeflemek olur. Yazının okunabilirliği ile videonun akıcılığı arasında görüntü kalitesi, iletişim miktarı ve işleme yükü tercihleri de farklıdır. Bkz. iş yüküne göre farklar.

GPU’nun var olup olmadığıyla yetinmeden, sorunlu aşamada GPU’nun kullanılıp kullanılmadığını ve aynı işlemin yükü ile yanıtının nasıl değiştiğini kaydedebilirsiniz. İyileşme sağlamayan değişiklikler yöneticiyle teyit edilerek geri alınır.

flowchart TB
    accTitle: GPU kullanımını aşama aşama kontrol etmek
    accDescr: Uzak bilgisayardaki uygulamanın çizimini, RDP kodlamasını ve yerelde kod çözmeyi ayırır; GPU olsa bile tüm aşamaların GPU'yu kullandığı kesin olmadığından şüpheli aşamadaki kullanımı kontrol eder.
    A["Uzaktaki uygulamanın çizimi"] --> B["RDP kodlaması"]
    B --> C["Yerelde kod çözme"]
    C -.- D["Aşama bazında GPU kullanımını kontrol et"]

Şekil 18: GPU olsa bile çizim, kodlama ve kod çözmenin tümünün GPU’yu kullandığı kesin değildir.

Yeniden doğrulama ve devretme

İyileşme, değişiklikten sonra aynı işlemin sorunsuz yapılabilmesinin yanı sıra gereken görüntü kalitesinin, cihazların ve iş işlevlerinin korunmasıyla doğrulanır. Özgün koşullara dönüldüğündeki sonucu da eşleştirin. Yalnızca anlık bir düzelme varsa nedeni kesinleştirmeyin; yoğun saatleri ve eşzamanlı işlemeleri de içerecek şekilde kaydedin.

flowchart TB
    accTitle: İyileşmeyi doğrulama sırası
    accDescr: Değişiklikten sonra aynı işlemin sorunsuz yapılıp yapılamadığına ek olarak gereken görüntü kalitesinin, cihazların ve iş işlevlerinin korunup korunmadığını doğrulamayı, özgün koşullara dönülünce elde edilen sonuçla eşleştirmeyi ve yalnızca anlık bir düzelmeyle nedenin kesinleştirilmediğini gösterir.
    A["Değişiklik sonrası aynı işlemi dene"] --> B["Görüntü, cihaz ve işlevleri doğrula"]
    B --> C["Özgün koşul sonucuyla eşleştir"]
    C -.- D["Anlık düzelmeyle kesinleşmez"]

Şekil 19: Aynı işlemin sonucuna ek olarak gereken işlevleri ve geri alınınca elde edilen sonucu da eşleştirin.

Çözülemediğinde devretme

İyileşmemesi, yeniden üretilememesi veya sayaçların kullanılamaması da yararlı sonuçlardır. Yapabildiğiniz karşılaştırmaları yapamadığınız kontrollerden ayırın ve aşağıdaki notla yöneticilere ve geliştiricilere devredin. Paylaşılan günlüklerden kullanıcı adları ve bağlantı hedefleri gibi inceleme için gereksiz iş bilgilerini çıkarın.

Belirtinin görüldüğü saat ve saat dilimi:
Uzak bilgisayarın işletim sistemi, kullanılan istemci ve sürümü:
Doğrudan/VPN/RD Gateway/Azure Virtual Desktop vb.:
Yavaş işlem ve uygulama, aynı oturumdaki başka uygulamanın tepkisi:
Uzak taraftaki çözünürlük ve monitör sayısı:
Aynı anda süren kopyalama, yazdırma vb.:
Değiştirilen tek koşul ve geri alınınca elde edilen sonuç:
Uzak ve yerel bilgisayarda gözlenen yük ve sayaçlar:

Gerçek TCP/UDP kullanımının doğrulanıp doğrulanamadığını, izin yetersizliği gibi nedenlerle kontrol edilemeyen maddeleri ve iş açısından kabul edilebilir ayarları da ekleyin. “Bağlantı yavaş” demek yerine “Not Defteri’nde normal yazabiliyorum ama fotoğrafları kaydırınca donuyor” demek, bir sonraki sorumlunun aynı koşullarda incelemesini sağlar.

Kullanıcılar sorunu yeniden üreten işlemi ve karşılaştırma sonuçlarını kayda geçirir; yöneticiler bağlantı yolu, paylaşılan ana bilgisayar ve oturum kayıtlarını eşleştirir. Yalnızca RDP üzerinde beklendiği gerçeği, bekleten işlemenin de RDP olduğu anlamına gelmez. Bkz. ana bilgisayar ile arka uç arasındaki iş bölümü.

Uygulama geliştiricileri girdi olaylarının alınmasını, veritabanı ve dosya işlemlerinin başlangıcını ve bitişini ve arayüze yansıtılmasını ayrı ayrı kaydeder. Ağır işlerin UI iş parçacığında oturup kalmadığı bir tasarımı da değerlendirir. Ancak uzak bilgisayardaki işlemenin tamamlandığını gösteren günlük, yerelde görüntülemenin tamamlandığını kaydetmez. Bkz. arayüzün yanıt verebilirliğini korumak için işlemelerin ayrılması.

İlgili makaleler

• Windows’ta oturum yalıtımı nasıl anlaşılmalı?
• Windows’ta %100 disk kullanımını güvenli biçimde ayrıştırmak
• “1 saniye kaldı” neden bitmez?

Kaynaklar

Microsoft Learn’deki birincil kaynaklardır. Başvurulan içerik 17 Eylül 2026’da kontrol edilmiştir. Ürüne göre değişen geçerlilik koşullarını ve bunların bu makalede yapılmış ölçümler olmadığını ayırt ederek okuyun.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. RTT ile uzak bilgisayarda ekranın yakalanmasından yerelde görüntülenmesine kadarki gecikmenin ayrımı. Tanılama özelliğinin kendisi Azure Virtual Desktop içindir.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. Ekran içeriği, çözünürlük, kare güncellemesi, sıkıştırma ve önbellekleme ile iletişim miktarı arasındaki ilişki.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. Ekran karelerinin girişi ve çıkışı, kare atlama nedenleri ve kodlama süresinin kontrol yöntemi. Eski yapıların açıklamalarını içerdiğinden sayısal üst sınırları tüm RDP’lere genellemeyiz.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. Paylaşılan ana bilgisayarın yükü, uzak bilgisayardan arka uca iletişim ve cihaz yeniden yönlendirmesinin etkisi.
• Microsoft Learn, Threading model. WPF’teki UI iş parçacığı ve Dispatcher, yanıt verebilirliği korumak için işlemelerin ayrılması.
• Microsoft Learn, mstsc. Uzak Masaüstü’nün genişlik ve yüksekliğinin ve birden çok monitörün belirtilmesi.
• Microsoft Learn, Supported RDP properties. Masaüstü çözünürlüğü, dinamik çözünürlük ve smart sizing arasındaki ayrım. Desteklenen istemcileri ve ürüne göre geçerlilik koşullarını kontrol edin.
• Microsoft Learn, ping. ICMP Echo ile yanıtın kontrolü ve seçenekler.
• Microsoft Learn, Test-NetConnection. TCP bağlantısının kontrolü ve çıktının anlamı.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. User Input Delay sayacının ölçtüğü aralık, hedef işletim sistemleri, örnekler ve en büyük değerin anlamı.
• Microsoft Learn, query session. Oturum bilgileri ve diğer oturumları sorgulamak için gereken izinler.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. RDP’nin kullandığı TCP/UDP seçimi ve geri dönüş.
• Microsoft Learn, RDP Shortpath. Azure Virtual Desktop için UDP yolu ve kurulamadığı durumdaki davranış.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. Çizim ile kare kodlamayı ayıran GPU yapılandırması ve doğrulaması.

İlgili Makaleler

Aynı etiketleri paylaşan en yeni makaleler. Birbirine yakın konularla bilginizi derinleştirebilirsiniz.

İlgili Konular

Bu konuya yakın konu sayfaları. Makaleden yola çıkarak ilgili hizmetlere ve diğer makalelere geçebilirsiniz.

Bu Konunun Bağlantılı Olduğu Hizmetler

Bu makale aşağıdaki hizmet sayfalarıyla ilişkilidir. Size en yakın başlangıç noktasından göz atabilirsiniz.

Sık Sorulan Sorular

Bu makalenin konusuyla ilgili olarak danışmanlık sırasında sık sorulan soruları derledik.

Hız testinde yüzlerce Mbps çıkıyorken RDP'de girdi neden yavaş?

Büyük verileri taşıma hızı ile bir işleme yanıt dönene kadar geçen süre ayrı şeylerdir. Girdinin gönderilmesi, uzak bilgisayardaki uygulamanın işlemesi, ekranın sıkıştırılması, aktarım ve yerel bilgisayarda görüntüleme işin içine girer. Ayrıca hız testinin karşı tarafına giden iletişim yolu ile RDP'nin bağlandığı bilgisayara giden yol da farklıdır.

Yazı normal yazılıyor ama yalnızca kaydırma takılıyor. Bu bağlantı sorunu mu?

Neden yalnızca bağlantıya indirgenemez. Ekran güncellemeleri arttığında uzak bilgisayardaki çizim ve sıkıştırma, iletişim ya da yerel bilgisayardaki kod çözme ve görüntülemeden biri yetişemiyor olabilir. Uzak taraftaki çözünürlüğü veya monitör sayısını birer birer değiştirerek karşılaştırın; gerekirse çizimle ilgili sayaçları inceleyin.

Ping hızlıysa RDP iletişimi normal midir?

Yalnızca buna bakarak karar verilemez. Ping, ICMP'ye verilen yanıtı ölçer; RDP'nin ekran aktarımını ve uygulama işlemesini ölçmez. RD Gateway gibi bileşenlerin kullanıldığı yapılarda yol da örtüşmeyebilir. Yanıt gelmediğinde de ICMP'nin engellenmesini RDP'nin kendisine ulaşılamamasından ayırın.

User Input Delay, bir tuşa basıldıktan sonra karakterin görünmesine kadar geçen süre midir?

Hayır. Uzak bilgisayarda girdinin kuyruğa girmesinden sürecin onu almasına kadar geçen bekleme süresini ölçen bir sayaçtır. İletişimin gidiş-dönüşünü, girdi alındıktan sonraki uygulama işlemesini ve ekranın sıkıştırılması, kodunun çözülmesi ve görüntülenmesini kapsayan algılanan gecikme değildir.

RDP yavaşken UDP'yi devre dışı bırakmalı mıyım?

Genel bir kural olarak önermiyoruz. Önce gerçek bağlantı yöntemini, yolu ve uygulanan ilkeleri kontrol edin. UDP kullanılamadığı için zaten TCP'ye geri dönülmüş olabilir ve yalnızca TCP'ye geçmek her zaman hızlandırmaz. Yöneticinin izniyle koşulları eşitleyerek karşılaştırın ve gereksiz değişiklikleri geri alın.

Yazar Profili

Makale yazarının profil sayfası.

Go Komura

KomuraSoft LLC Temsilcisi

Windows yazılım geliştirme, teknik danışmanlık ve hata araştırması odaklı çalışır; mevcut varlıkların korunduğu projelerde ve nedeni kolay anlaşılamayan arızaların araştırılmasında güçlüdür.