Miks RDP on aeglane, kuigi ühendus on kiire? – Sisendi, renderdamise ja võrguliikluse eraldi uurimine

Kiirustest näitab mitusada Mbps, kuid kaugtöölauas ilmuvad märgid väikese viivitusega. Paljude fotodega lehe kerimisel jääb pilt toppama. Ärirakenduses peatub kõik mõneks sekundiks ainult siis, kui vajutate otsingut. Kust alustada sellise olukorra uurimist, kus „ühendus on kiire, kuid RDP on aeglane“?

RDP reageerimine kasutaja toimingutele ei sõltu ainult ühenduse edastuskiirusest. Isegi kui kiirustest on kiire, võib ootamine tekkida võrgu edasi-tagasi liikumisel, kaugarvuti rakenduse sisendi ootamisel, ekraanipildi kodeerimisel või kohalikus arvutis dekodeerimisel ja kuvamisel. Kõigepealt eristage, „milline toiming on aeglane“, ja võrrelge sama toimingut, muutes korraga ainult üht tingimust. Kitsendage võrdluste ja mõõtmistega uurimise suunda ning valige UDP ja GPU sätted vastavalt nende tulemustele. Vt: Ühenduse kvaliteedi mõõtelõigud, Seansihosti jõudlust mõjutavad tegurid.

Samas ei ole algpõhjus veel kindlaks tehtud, kui olete uurimise suunda alles kitsendanud. Isegi kui eraldusvõime vähendamine olukorda parandab, muutub lisaks võrguliiklusele ka ekraanitöötlus mõlemas otsas, mistõttu me ei väida kindlalt, et „põhjus oli ühenduses“. Pange tulemused kirja, eristades mõõdetud ja mõõtmata lõike.

Selles artiklis eristame pärast ühenduse loomist sisestamise, kerimise ja rakenduse reageerimise probleeme. Ka sarnaste sümptomite korral ei pruugi põhjus olla üks. Juhtumeid, kus „sisselogimiskuva ilmumine võtab kaua aega“ või „kõik peatub autentimisel“, käsitleme eraldi probleemina, mida uuritakse ühenduse loomise ja autentimise logide põhjal.

Artikkel on mõeldud peamiselt kasutajatele ja administraatoritele, kes loovad Windowsi rakendusega „Kaugtöölaua ühendus“ (mstsc) ühenduse Windows 11 või Windows Serveriga. Käsunäited on mõeldud Windows PowerShell 5.1 jaoks. Eeldame, et sama toimingut saab korrata juba loodud seansis.

Otseühenduse, VPN-i, RD Gateway ja Azure Virtual Desktopi puhul erinevad ühendustee, saadaolev diagnostikateave ja see, millele sätted rakenduvad. TCP 3389 kontrollinäide kehtib ainult lubatud otseühendusele RDP-hostiga, mis kasutab standardporti. Azure Virtual Desktopi materjalides kirjeldatud diagnostikafunktsioone ja GPU sätteid ei rakendata muutmata kujul tavalistele ettevõtte arvutitele.

Ettevõtte seadmetes uurige ainult administraatori lubatud ulatuses. Jagatud hostis tuvastage oma seanss ja asjaomane protsess ning kui vajate teiste kasutajate andmeid, pöörduge administraatori poole. Jõudlusloendurite saadavust, kuvatavaid nimesid ja vajalikke õigusi kontrollige iga keskkonna puhul eraldi.

Siin toodud kontrollimeetodid põhinevad ametlikel materjalidel. Need ei ole mõõtmisaruanne rikke kordamise ja kõrvaldamise kohta konkreetses seadmes. Arvnäidete puhul märgime selgelt, kui tegu on selgitava oletusega.

Mehhanismi saate lugeda järjest, alustades järgmisest jaotisest „Edastuskiirus ja edasi-tagasi aeg“. Kui soovite alustada sümptomist, liikuge jaotisse „Esimene võrdlus sümptomi järgi“. Toimingute juhised on jaotistes „Tingimuste võrdlemine ükshaaval“ ja „Ootekoha mõõtmine“.

Diagrammil tähistab pidev joon seost, mis kehtib alati, ja katkendjoon tingimuslikku seost (tingimused on igal seosel toodud üksikasjalikul lehel). Seoste täielik loend (7 kokku, koos tõendite ja kindlusastmega) ning põhimõistete definitsioonid on koondatud teadmuskaardi üksikasjalikule lehele (jaapani keeles). Andmed: JSON-LD / Turtle

Edastuskiirus ja edasi-tagasi aeg

RDP (Remote Desktop Protocol) on protokoll, millega kohalik seade ja kaugarvuti vahetavad sisendit, ekraaniteavet jms. Lisaks ekraanile ja sisendile edastab see ka seadmete ümbersuunamise, printimise ja muud teavet. Vt: RDP kaudu edastatav teave.

Ühenduse edastuskiirus näitab, kui palju andmeid saab ühe sekundi jooksul edastada. Kiirustesti „500 Mbps“ on just selle mahu näitaja. See ei näita aega, mis kulub toimingust vastuse saabumiseni. Vt: RDP ribalaiuse nõuded.

flowchart TB
    accTitle: Mida kiirustesti number näitab
    accDescr: Kiirustesti 500 Mbps näitab ühe sekundi jooksul edastatavat andmemahtu ning on eraldi number ajast, mis kulub toimingust vastuse saabumiseni.
    A["Kiirustest: 500 Mbps"] --> B["Sekundis edastatav andmemaht"]
    B -.->|"teine number"| C["Aeg vastuse saabumiseni"]

Joonis 1: Kiirustesti number näitab edastatavat mahtu, mitte aega vastuse saabumiseni.

Edasi-tagasi aeg (RTT) on aeg, mille jooksul andmed jõuavad vastaspooleni ja tulevad tagasi. Edastuskiiruse suurendamise ja edasi-tagasi aja lühendamise erinevus sarnaneb erinevusega tee sõiduradade lisamise ja sihtkohani jääva vahemaa lühendamise vahel. Isegi kui võime suuri failihulki edastada kasvab, jääb toimingu vastuse ootamine alles, kui edasi-tagasi aeg jääb samaks. Vt: RTT ja ekraanikuva viivitus.

flowchart TB
    accTitle: Edastuskiirus ja edasi-tagasi aeg tee näitel
    accDescr: Joonis võrdleb edastuskiiruse suurendamist tee sõiduradade lisamisega ja edasi-tagasi aja lühendamist sihtkohani jääva vahemaa lühendamisega.
    A["Suurenda edastuskiirust"] -->|"teel oleks see"| B["Lisa sõiduradu"]
    B ~~~ C["Lühenda edasi-tagasi aega"]
    C -->|"teel oleks see"| D["Lühenda vahemaad"]

Joonis 2: Sõiduradade lisamine ei lühenda vahemaad sihtkohani.

Kuni ühe märgi tulemus tagasi jõuab

Kujutame ette, et sisestate kaugarvuti Märkmikku ühe märgi. Märkmik töötab kaugarvutis. Kui selgituse huvides oletada, et toimingu kohalejõudmiseks kulub 50 millisekundit ja tulemuse ekraaniteabe tagasijõudmiseks 50 millisekundit, kulub võrguliiklusele kokku 100 millisekundit ehk 0,1 sekundit. Töötlusaeg mõlemas otsas on sellest näitest välja jäetud.

flowchart TB
    accTitle: Näide võrguajast, kuni ühe märgi tulemus tagasi jõuab
    accDescr: Selgitav näide, kus nii edasi- kui ka tagasitee kestuseks oletatakse 50 millisekundit. Töötlusaeg mõlemas otsas ei ole arvestatud ning joonis ei näita pakettide arvu klahvivajutuse kohta.
    A["Sisestate kohalikult ühe märgi"] -->|"edasi: 50 ms"| B["Kaugarvuti võtab sisendi vastu"]
    B --> C["Saadab sisendiga kuva"]
    C -->|"tagasi: 50 ms"| D["Tulemus jõuab kohalikku arvutisse"]

Joonis 3: Kui edasitee võtab oletatavalt 50 millisekundit ja tagasitee 50 millisekundit, kulub ainuüksi võrguliiklusele 0,1 sekundit. Tegu ei ole mõõdetud väärtusega.

Isegi kui ühenduse kaudu saab edastada rohkem andmeid, jääb see 0,1 sekundit alles, kui edasi-tagasi aeg ei muutu. Joonis 3 on kontseptuaalne joonis töötluse mõistmiseks. See ei tähenda, et iga klahvivajutuse kohta saadetakse eraldi edasi-tagasi pakett. Kiirustesti serveri ja RDP kaugarvuti puhul erineb ka võrgutee, mistõttu tuleb arvesse võtta VPN-i, lüüsi, kaugarvuti poole üleslaadimist ja ummikut teel. Vt: RTT käsitlus, Võrgu ja hosti jõudlus.

Ekraanipildi loomine ja kohaletoimetamine

Toimingule reageerimise viivitus tähendab siin ootamist alates toimingust kohalikus arvutis kuni tulemuse nähtavaks muutumiseni. Mõju avaldab mitte ainult RTT, vaid ka rakenduse töötlus ning ekraanipildi loomine ja kohaletoimetamine. Eristame seda ka viivitusest, mis puudutab ainult ekraanipildi edastuslõiku. Vt: Mõõtelõik ekraanipildi hõivamisest kuvamiseni.

Kui sisend jõuab kohalikust arvutist kaugarvutisse, töötleb kaugarvuti rakendus sisendit ja värskendab ekraani, kodeeritud ekraaniteave edastatakse üle võrgu ning kohalik arvuti dekodeerib ja kuvab selle. Nii enne kui ka pärast võrguedastust on tööd, mida teevad eri arvutid. Vt: Töötlus ekraanipildi hõivamisest kuvamiseni.

flowchart TB
    accTitle: Ekraanitöötlus toimub ka enne ja pärast võrku
    accDescr: Voog, kus kohalik sisend jõuab kaugarvutisse, kaugarvuti rakendus töötleb selle, ekraanipilt luuakse ja tihendatakse ning võrgu kaudu toodud ekraaniteave taastatakse kohalikus arvutis kuvatavale kujule ja kuvatakse.
    I["Kohalik: sisestate toimingu"] --> J["Võrk: viib sisendi"]
    J --> K["Kaugarvuti: rakendus töötleb"]
    K --> A["Kaugarvuti: loob ja tihendab kuva"]
    A --> B["Võrk: viib ekraaniteabe"]
    B --> C["Kohalik: taastab kuvatavaks"]
    C --> D["Kuvatakse kohalikul ekraanil"]

Joonis 4: Kaugarvuti töötleb ja tihendab, võrk edastab ja kohalik arvuti taastab kuvamiseks. Iga töö tehakse eri kohas.

Kodeerimine tähendab selles artiklis töötlust, mis teisendab ja tihendab ekraanipildi kaugarvutis saatmiseks sobivale kujule. Lisaks võrguedastusele kulub sellele kaugarvutis töötlusaega. Vt: Kodeerimisaeg kaugarvutis.

Dekodeerimine tähendab selles artiklis töötlust, mis taastab saabunud ekraaniteabe kohalikus arvutis kuvatavale kujule. Eristame seda dekrüpteerimisest ehk krüpteeringu eemaldamisest. Vt: Dekodeerimis- ja kuvamisaeg kohalikus arvutis.

Kui tihendamine kaugarvutis võtab aega, tuleb saatmise ettevalmistust oodata ka siis, kui ühendus on vaba. Isegi kui teave on kohale jõudnud, hilineb värskendus, kui kohalik dekodeerimine või kuvamine ei pea sammu. Ei saa eeldada, et „töökoha arvuti on võimas, seega pole kohalikul seadmel tähtsust“. Ühenduse varu ja töötlusvaru selle mõlemas otsas on eri asjad. Vt: Ekraanitöötluse jõudlusloendurid.

flowchart TB
    accTitle: Viivitus, kui mõlema otsa töötlus ei pea sammu
    accDescr: Näitab, et kui tihendamine kaugarvutis võtab aega, tuleb saatmise ettevalmistust oodata ka vaba ühenduse korral, ja kui kohalik dekodeerimine või kuvamine ei pea sammu, hilineb värskendus ka kohale jõudnud teabe korral.
    A["Tihendamine kaugarvutis on aeglane"] --> B["Saatmine ootab ka vaba ühendusega"]
    B ~~~ C["Kohalik dekodeerimine jääb maha"]
    C --> D["Värskendus hilineb ka kohale jõudes"]

Joonis 5: Isegi kui ühendusel on varu, hilineb ekraani värskendus, kui mõlema otsa töötlus ei pea sammu.

Teksti sisestamise ja kerimise erinevus

Kui lisate Märkmikku ühe märgi, muutub ainult väike osa ekraanist. Paljude fotodega lehe kerimisel muutub suur osa kuvast järjest. RDP vähendab andmemahtu, edastades muutunud osi ning kasutades sisule sobivat tihendamist ja vahemälu. See ei saada iga kord kogu ekraani tihendamata kujul. Töömaht sõltub ekraani sisust ja värskendamise sagedusest. Vt: Ekraani sisu ja ribalaiuse seos.

flowchart TB
    accTitle: Teksti sisestamisel ja kerimisel muutuv ekraanitöö maht
    accDescr: Väike märgimuutus ja suure ala pidev värskendamine erinevad ekraanipildi loomise ja saatmise töö olemuse poolest.
    A{"Ekraani muutus"} -->|"üks märk juurde"| B["Väike ala"]
    A -->|"kerimine"| D["Suur ala järjest"]
    B --> E["Tihendus ja edastus muutuse järgi"]
    D --> E

Joonis 6: Ka sama ühenduse puhul on töömaht erinev, kui lisatakse üks märk või kui suur ala liigub pidevalt.

Isegi kui staatiline dokument on kerge, võib ekraanipildi edastusel kerimise ajal varu otsa saada. Kui suurendada kaugpoole eraldusvõimet või monitoride arvu, suureneb ka töödeldav ekraan. Eraldusvõime vähendamisega võrdlemine on katse, mis näitab, kas liikumine muutub taas sujuvaks, kui ekraanipildi loomise ja saatmise tööd vähendada. See ei ole arvutus, mis määraks andmemahu ainult pikslite arvu põhjal. Vt: Eraldusvõime, ekraani värskenduse ja tihendamise mõju.

Rakenduse ootamine

Kui ainult ärirakenduse otsing peatub mõneks sekundiks, kuid samas seansis saab Märkmikku tavapäraselt kirjutada, kontrollige, mida see rakendus ootab. Kaugarvuti rakendus võib omakorda saata päringu teise andmebaasi või lugeda faili ühiskaustast ja oodata selle vastust. See on RDP-liiklusest eraldi tee; RDP-liiklus ühendab kohalikku arvutit ja kaugarvutit. Vt: Liiklus kaugarvutist taustasüsteemidesse.

flowchart TB
    accTitle: Ka RDP taga on suhtluspartnereid
    accDescr: Näitab juhtumit, kus lisaks kohalikku seadet ja kaugarvutit ühendavale liiklusele ootab kaugarvuti rakendus äriserveri vastust.
    A["Kohalik seade"] -->|"RDP"| B["Kaugarvuti ärirakendus"]
    B -->|"otsing, failipäring"| C["Andmebaas, ühiskaust"]
    C -->|"oodatav vastus"| B

Joonis 7: RDP taga olev ärirakendus võib omakorda oodata mõne teise serveri vastust.

Kui ekraani ja sisendi eest vastutav töötlus on hõivatud pika tööga, hilinevad järgmine sisend ja ekraani värskendus. Näiteks WPF-is kannatab reageerimisvõime, kui UI-lõim on pikalt hõivatud. Ainuüksi madal kogu CPU kasutus ei välista konkreetse UI-lõime ootamist. Vt: Dispatcher ja UI-lõim.

flowchart TB
    accTitle: Ekraani ja sisendi eest vastutav töötlus ummistub
    accDescr: Näitab, et kui ekraani ja sisendi eest vastutav töötlus on hõivatud pika tööga, hilinevad järgmine sisend ja ekraani värskendus ning ainuüksi madal kogu CPU kasutus seda ootamist ei välista.
    A["Ekraani ja sisendi töötlus"] --> B["Hõivatud pika tööga"]
    B --> C["Järgmine sisend ja värskendus hilinevad"]
    C -.- D["Madal kogu CPU ei välista"]

Joonis 8: UI-lõime ootamist ei saa välistada ainult kogu CPU kasutuse põhjal.

Esimene võrdlus sümptomi järgi

Edastatav maht, vastuse ootamise aeg ning ekraanipildi loomise ja kuvamise aeg on eri asjad. Kui seda eristust silmas pidada, ei pea „RDP on aeglane“ taandama ühele põhjusele ning uurimist saab alustada toimingust, mis on praegu aeglane.

flowchart TB
    accTitle: Eristage kolme asja ja alles siis uurige
    accDescr: Näitab, et „RDP on aeglane“ ei taandata ühele põhjusele, vaid edastatav maht, vastuse ootamise aeg ning ekraanipildi loomise ja kuvamise aeg eristatakse ja uurimist alustatakse praegu aeglasest toimingust.
    A["„RDP on aeglane“"] --> S
    subgraph S["Vaadake eraldi"]
    direction TB
    B["Edastatav maht"] ~~~ C["Vastuse ootamise aeg"]
    C ~~~ D["Kuva loomise ja näitamise aeg"]
    end
    S --> E["Uurige praegu aeglast toimingut"]

Joonis 9: Kui eristate edastatava mahu, vastuse ootamise aja ning ekraanipildi loomise ja kuvamise aja, saate alustada praegu aeglasest toimingust.

Eristamise eesmärk on piirata kohta, kus aeglust uurida. Eesmärk ei ole muuta sätteid hulgi ja saada juhuslikult kiirem tulemus. Kui kasutate erinevusi nagu „Märkmik töötab, kuid ainult otsing peatub“ või „teksti sisestamine on tavaline, kuid ainult kerimine on aeglane“, saate uurimise lähtepunkti valida juba enne võrgusätete muutmist.

Järgmine tabel on uurimise lähtepunkt. See ei ole tabel põhjuse kindlakstegemiseks. Võrrelge esmalt toiminguid samas seansis ja alles seejärel muutke vajaduse korral seadet, ühendusteed või kuvatingimusi.

Märgid hilinevad mitmes rakenduses

Kui samas seansis hilinevad märgid mitmes rakenduses, võrrelge sama toimingut ka teisest seadmest või teise lubatud tee kaudu. Kõrvutage edasi-tagasi aega, sisendi ootamist kaugarvutis ja kaugarvuti üldkoormust ning ärge tehke põhjust kindlaks ühe arvu põhjal.

Ainult kerimine hakib

Isegi kui teksti sisestamine on tavaline, järgneb paljude fotodega lehe kerimisel suure ala värskendusi üksteise järel. Muutke kaugpoole eraldusvõimet või monitoride arvu ükshaaval ja võrrelge sama lehega. Kui olukord paraneb, on järgmised uurimisobjektid tihendamine kaugarvutis, ekraanipildi edastus ja kohalik dekodeerimine. Ainult eraldusvõime põhjal ei selgu, milline neist kolmest on põhjus. Vt: Ekraani sisust ja eraldusvõimest tulenev koormus.

Ainult üks rakendus hangub

Kui peatub ainult see ärirakendus, kus vajutasite otsingut, võrrelge, kas Märkmik vms samas seansis reageerib. Kui teised rakendused töötavad, uurige esmalt asjaomase rakenduse töötlust, ketast ning päringuid andmebaasi ja ühiskausta. See, et töötate RDP kaudu, ja see, et ootamise põhjus on RDP-liiklus, on eri asjad. Vt: Rakenduse ja taustasüsteemide jõudlustegurid.

Kõigil on aeglane ainult kasutajate rohkuse ajal

Kui samal ajal muutub töö aeglaseks mitmel kasutajal, küsige administraatorilt teiste seansside olukorra kohta. Kõrvutage jagatud hosti CPU, mälu ja salvesti ning jagatud ühenduse koormust sümptomi ajaga. Ärge pääsege ilma loata ligi teiste kasutajate andmetele ega töötlustele ja ärge peatage nende töid. Vt: Jagatud hosti ressursid ja kasutajate arv.

Aeglustumine kopeerimise või printimise ajal

Kui probleem langeb ajaliselt kokku sellega, et alustasite kopeerimist või printimist, peatage võrdluseks ajutiselt ainult need edastused, mille peatamine on lubatud. Pange kirja, kas olukord taastub pärast peatamist ja kas jätkamisel muutub töö taas aeglaseks, ning uurige konkurentsi muu kui ekraaniliikluse ja seadmete ümbersuunamisega. Ärge tehke võrdlust, mille käigus keelatakse hulgi tööks vajalikud seadmed. Vt: Seadmete ümbersuunamise mõju.

Tingimuste võrdlemine ükshaaval

Kõiki sätteid ei ole vaja järjest muuta. Looge kõigepealt võrdlusalus ja valige ainult sümptomile vastavad kontrollid. Enne sätete muutmist ja uuesti ühendamist salvestage oma töö ning pange kirja algsed väärtused ja nende taastamise viis. Kui vajalikke õigusi või funktsioone ei ole, ärge lülitage neid jõuga sisse, vaid andke küsimus üle administraatorile.

Kohalik kasutamine ja RDP kaudu kasutamine ei pruugi toimuda samadel tingimustel. See, et kaugarvuti enda ekraanil töötab kõik kiiresti, on kasulik teave, kuid seanss ja renderdamistingimused võivad erineda. Ühtlustage kasutaja, andmed ja rakenduse olek ning ärge piirake põhjust ühendusega ainult sellepärast, et „arvuti enda ekraanil on kiire“.

Sama toimingu võrdlemine

Valmistage ette sama kasutaja, samad andmed ja sama toiming. Jagatud hostis kontrollige oma seanssi ning ärge peatage teiste kasutajate rakendusi ega töötlusi. Ka teist seadet või teist teed kasutage ainult administraatori lubatud ulatuses.

1. Korrake aeglast toimingut algsete sätetega ning pange kirja aeg ja sümptom.

   Sisestage samas kaugseansis, kus probleemne rakendus töötab, Märkmikku umbes sama palju teksti. Eristage, kas probleem puudutab ainult üht rakendust või kogu seanssi.

2. Kontrollige samal ajavahemikul kaugarvuti ja kohaliku arvuti koormust.

   Vaadake Tegumihalduris kaugarvutis asjaomase rakenduse CPU, mälu ja ketta kasutust ning kohalikus arvutis RDP-kliendi koormust. Kontrollige lisaks kogu CPU väärtusele ka asjaomast protsessi. Vt: Mida koormuse uurimisel vaadata.

3. Muutke ainult üht tingimust – seadet, lubatud ühendusteed või kuvatingimusi – ja korrake sama toimingut.

   Kui võrdluse käigus muutub samal ajal ka kaugarvuti või rakenduse olek, pange ka see erinevus kirja. Ärge käsitlege tulemust, mille puhul muutus mitu tingimust, ühe tingimuse mõjuna.

4. Taastage algsed tingimused ja kontrollige sama toimingut uuesti.

   Kui töö jääb kiireks ka pärast taastamist, võib põhjus olla näiteks ajutine koormuse muutus. Ärge järeldage kindlalt, et muudatus mõjus, vaid pange kirja tingimused, mille korral sümptom kordub.

Nii saate kokku tulemused algses olekus, pärast muudatust ja pärast taastamist ning saate võrrelda, millised tingimused ja sümptomid vastavad teineteisele. Olukorda parandanud tingimus on uurimise vihje ega tõenda üksi algpõhjust.

flowchart TB
    accTitle: Korraga muudetavate tingimuste piiramine
    accDescr: Voog, kus valitakse algses olekus korduv toiming, muudetakse võrdluseks ainult üht tingimust ja kontrollitakse ka tulemust pärast taastamist.
    A["Sama toiming algsätetega"] --> B["Muuda ainult üht tingimust"]
    B --> C["Korda sama toimingut"]
    C --> D["Taasta ja kontrolli uuesti"]
    D --> E["Pane paranenud tingimus kirja"]

Joonis 10: Korrake sama toimingut algses olekus, pärast muudatust ja pärast taastamist ning pange kirja muutunud tingimus.

Kaugpoole eraldusvõime võrdlemine

Tehke see võrdlus siis, kui ekraani värskendamine, näiteks kerimine, on aeglane. Pange kirja eraldusvõime ja monitoride arv enne muudatust, salvestage oma töö ja looge siis ühendus uuesti. Ärge jätke püsivalt kasutusse sätet, mis kahjustab tööks vajalikku ekraani või teksti loetavust.

1. Muutke ainult üht: kas monitoride arvu või eraldusvõimet.

   mstsc-is saate võrrelda enne ühendamist vahekaardi „Kuva“ sätete või laiuse ja kõrguse määramise abil. Vt: Kuva määramine mstsc-is.

2. Veenduge, et kaugtöölaua tegelik suurus muutus, ja kerige sama lehte.

   Kui ainult vähendate kohalikku akent, võib juhtuda, et suurt töölauda kuvatakse lihtsalt vähendatult. Eristage dünaamilist eraldusvõimet ja smart sizingut ning kontrollige kasutatava kliendi toetustingimusi. Vt: Töölaua eraldusvõime ja kuvamise mastaap.

3. Taastage algsätted, korrake sama toimingut ning võrrelge mõlema otsa koormust ja ekraani liikumist.

   Kui muutsite korraga eraldusvõime madalamaks ja monitoride arvu üheks, jääb võrdlus ligikaudseks. Kui olukord paraneb, taastage need ükshaaval ja eristage nende mõju.

Kui olukord paraneb, on vihje ekraanitöötluse ja ekraanipildi edastuse valdkonnas. Eraldusvõimel 3840×2160 on neli korda rohkem piksleid kui eraldusvõimel 1920×1080, kuid andmemaht ei ole alati neli korda suurem. See sõltub muutunud osadest ja tihendamisest ning eraldusvõime muutmine mõjutab ka töötlust mõlemas otsas. Vt: Pikslite arvu ja andmemahu seos, Ekraanitöötluse kontrollimine.

flowchart TB
    accTitle: Mida eraldusvõime vähendamisega võrdlus näitab
    accDescr: Kaugpoole eraldusvõime vähendamine võib muuta nii ekraanitöötluse kui ka edastuse koormust, mistõttu ainult paranemise põhjal ei saa põhjust ühendusega piirata.
    A["Vähenda kaugpoole eraldusvõimet"] --> S
    subgraph S["Muutuv töötlus"]
    direction TB
    B["Kaugarvuti ekraanitöötlus"] ~~~ C["Saadetav teabe hulk"]
    C ~~~ D["Kohalik kuvamistöötlus"]
    end

Joonis 11: Eraldusvõime muutmine on võrdlus, mis mõjutab lisaks ühendusele ka kaugarvuti ja kohaliku arvuti ekraanitöötlust.

Kopeerimise, printimise ja sümptomi kõrvutamine

Ajutiselt peatage ainult töötlusi, mille peatamine on lubatud, näiteks enda alustatud edastusi. Ärge peatage ettevõtte varundus- ja turbetöötlusi ega teiste kasutajate töid. Ärge keelake hulgi tööks vajalike heli- ja sisendseadmete ümbersuunamist.

1. Pange kirja sama toiming ja koormus enne kopeerimise, pilvesünkroonimise või printimise algust ja nende ajal.

   RDP kaudu liigub lisaks ekraanile ka draivide, printerite jms teave. Ümbersuunamine, mis võimaldab kohalikke seadmeid kaugarvutis kasutada, võib kasutamise ajal suurendada liiklus- ja töötluskoormust. Vt: Seadmete ümbersuunamise mõju.

2. Peatage asjaomane edastus lubatud ulatuses ajutiselt ja kontrollige sama toimingut uuesti.

   Kui saate võrdluseks edastust jätkata, pange kirja ka sümptom pärast jätkamist. Ka mittevajaliku seadmete ümbersuunamise katsetamisel muutke sätteid ükshaaval ja tagage, et saate algsed sätted taastada.

Nii saate otsustada, kas edastuse algus ja probleem ning peatamine ja taastumine vastavad teineteisele. Kui vastavus ilmneb, kõrvutage muu kui ekraaniliikluse ja jagatud ressursside koormust administraatori logidega.

flowchart TB
    accTitle: Probleemi eel- ja järelolukord samal ajateljel
    accDescr: Enne edastust, edastuse ajal ja pärast peatamist pannakse kirja sama toiming ja koormus ning võrreldakse probleemi ja tegevuse seost.
    A["Toiming ja koormus enne edastust"] --> B["Toiming ja koormus edastuse ajal"]
    B --> C["Toiming ja koormus pärast peatamist"]
    C --> D["Kas probleem ja taastumine vastavad"]

Joonis 12: Vaadake, kuidas sama toimingu aeglus ja koormus muutuvad enne edastust, selle ajal ja pärast peatamist.

Ootekoha mõõtmine

Kohalikust arvutist uurime võrgu edasi-tagasi aega ja TCP-ühendust, kaugarvutis aga sisendijärjekorra ootamist ja ekraani värskendamist. Kuna iga arv mõõdab ainult piiratud lõiku, lugege tulemusi koos jaotise „Mõõtmistulemuste kehtivusulatus“ tabeliga.

ICMP ja TCP-ühenduse kontrollimine

Käivitage kontroll kohalikus Windowsi seadmes. See on mõeldud ainult konfiguratsioonidele, kus ühendus luuakse ettevõtte kohtvõrgus või lubatud VPN-i kaudu otse RDP-hostiga, mis kasutab standardset TCP-porti 3389. RD Gateway või Azure Virtual Desktopi kaudu toimuvate ühenduste ja kohandatud porti kasutavate konfiguratsioonide puhul leppige kontrollitav sihtkoht kokku administraatoriga. Porte ei avata ega tulemüüri muudeta.

1. Sisestage lubatud sihtarvuti ning pange kirja ICMP vastuse ja TCP-ühenduse tulemused.

   $target = Read-Host 'Uurimiseks lubatud RDP-hosti nimi või IP-aadress'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'Määrake sihtarvuti.'
   }
       
   # Vaata ICMP vastuseaega mitu korda. Ebaõnnestumine üksi ei tähenda, et RDP ühendus puudub.
   ping.exe -n 20 $target
       
   # Kontroll ainult konfiguratsioonile, kus ühendus luuakse otse standardsele TCP-pordile 3389.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. Kõrvutage aeglase perioodi ja tavaolukorra tulemusi sümptomi aja ja tegeliku ühendusteega.

   20 korda tehtud ping on lühike vaatlus. Pange kirja väärtuste kõikumine ja vastuseta jäänud päringud, kuid arvestage, et ICMP võib olla blokeeritud. Ärge välistage katkendlikke seisakuid ainult keskmise põhjal, vaid kasutage ühenduse teavet ja administraatori liikluslogisid. Vt: Mida ping mõõdab.

TcpTestSucceeded: True tähendab, et TCP-ühendus määratud pordiga õnnestus. Ribalaiust, UDP-d, toiminguid pärast autentimist ega ekraani sujuvust see ei mõõda. Cmdletil Test-NetConnection ei ole UDP kontrollimiseks lülitit -UDP. Vt: Test-NetConnectioni süntaks ja tulemused.

Otsustage, pidades silmas teede ja teenuste erinevusi. RD Gateway vms puhul ei pruugi ICMP ja otsese TCP-ühenduse tee hostini kattuda tegeliku RDP-teega. Azure Virtual Desktopis on saadaval ühendusepõhine RTT ja ribalaiuse hinnang, kuid see diagnostikafunktsioon on mõeldud selle teenuse jaoks. Ärge välistage lühikesi seisakuid ainult keskmise põhjal. Vt: Azure Virtual Desktopi ühenduse kvaliteedi logid.

flowchart TB
    accTitle: Kontrollitud tee ja tegelik RDP-tee
    accDescr: RD Gateway vms kasutavates konfiguratsioonides ei pruugi kohalikust arvutist hostini kulgev ICMP ja otsese TCP-ühenduse tee kattuda tegeliku RDP-teega.
    A["Kohalik seade"] -->|"ICMP, otsene TCP"| C["RDP-host"]
    A -->|"tegelik RDP"| B["RD Gateway vms"]
    B --> C

Joonis 13: ICMP ja otsene TCP-ühendus hostini ning tegelik RDP ei pruugi kasutada sama teed.

Sisendijärjekorra ootamise mõõtmine

User Input Delay mõõdab ootamist sellest hetkest, kui sisend kaugarvutis järjekorda satub, kuni protsess selle välja võtab. See ei ole koguaeg klahvi vajutamisest märgi nähtavaks muutumiseni. Vt: User Input Delay definitsioon.

Uurige seda kaugarvuti kaugseansis. Microsofti toetustingimused on Windows 10 versioon 1809 või uuem ja Windows Server 2019 või uuem. Nende süsteemide puhul ei ole lubamiseks vaja registrisse kirjet lisada. Kontrollige kuvatavaid nimesid, õigusi ja loendurite olemasolu ning kui need ei ole saadaval, pange see asjaolu kirja ja pidage nõu administraatoriga. Vt: Toetustingimused ja sätted.

1. Pange samas seansis PowerShellis kirja kellaaeg ja seansi ID.

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

   Teiste kasutajate seansside päringuks võib olla vaja lisaõigusi. Asjaomase protsessi standardne eksemplari nimi on SessionID:ProcessID <Process Image>. Ärge segage ainult seansi ID põhjal sisse teiste kasutajate või samanimeliste protsesside väärtusi. Vt: query session õigused, Eksemplari tuvastamine.

2. Lisage perfmon.exe-s saadaolev User Input Delay per Process või User Input Delay per Session.

   Valige asjaomane protsess või seanss ja jälgige alguses vaikimisi ühesekundilise intervalliga. Eristage mitut seanssi koondavat koondeksemplari ja üksiku seansi väärtusi.

3. Korrake toimingut, mille puhul sisend on aeglane, ja võrrelge järjekorras ootamist sümptomi ajaga.

   Üksiku mõõteobjekti puhul näete mõõteintervalli suurimat ooteaega. Isegi kui väärtus on madal, jäävad alles viivitused töötluses pärast seda, kui rakendus on sisendi välja võtnud, ja tulemuse tagasijõudmisel kohalikku arvutisse.

Nii saate uurida, kas oodatakse kaugarvuti sisendijärjekorras. See on teistsugune näitaja kui tajutav aeg, mis hõlmab võrgu edasi-tagasi liikumist ja kuvamist kohalikus arvutis. Vt: Maksimumväärtuse ja mõõteintervalli tähendus.

flowchart TB
    accTitle: Lõik, mida User Input Delay mõõdab
    accDescr: Mõõtelõik ulatub kaugarvuti sisendijärjekorrast kuni hetkeni, mil rakendus sisendi välja võtab, ega hõlma sellele eelnevat ja järgnevat võrguliiklust ega ekraanikuva.
    A["Sisend jõuab kohalikust arvutist"] --> B["Satub kaugarvuti sisendijärjekorda"]
    B -->|"seda mõõdetakse"| C["Rakendus võtab sisendi välja"]
    C --> D["Rakenduse töötlus ja kuva edastus"]
    D --> E["Kuvatakse kohalikus arvutis"]

Joonis 14: Mõõdetakse ootamist kaugarvuti sisendijärjekorras. See erineb koguajast, kuni tulemus kohalikus arvutis nähtavaks muutub.

Ekraani värskenduste ja kaadrite vahelejätmise põhjuste uurimine

Valmistage ette toiming, mille puhul ekraan värskeneb pidevalt, näiteks kerimine. RemoteFX Graphics loendurite saadavust ja mõõtmiskohta tuleb kontrollida sõltuvalt OS-ist, hosti konfiguratsioonist ja õigustest. Siin loeme ainult saadaolevaid loendureid. Tegu ei ole juhisega vana RemoteFX-i funktsiooni paigaldamiseks ega lubamiseks. Vt: Graphics-loendurite rakendustingimused.

1. Kontrollige käsuga query session või qwinsta asjaomase seansi nime ja valige vastav loenduri eksemplar.

2. Võrrelge ekraani värskendava toimingu ajal väärtusi Input Frames/Second ja Output Frames/Second.

   Kui väljundkaadreid on vähem kui sisendkaadreid, jäetakse kaadreid vahepeal vahele. Kontrollige Frames Skipped/Second väärtusi, mis on jaotatud kaugarvuti, võrgu ja kliendi ressursipuuduse järgi.

3. Kõrvutage vahelejätmise põhjust mõlema otsa ja võrgu koormusega ning kontrollige ka väärtust Average Encoding Time.

   Kui kodeerimisaeg on pikk, uurige tihendamist kaugarvutis. Kui kaadreid on vähe juba sisendi poolel, võib ka olla, et rakendus ei värskenda ekraani sageli. Madal kaadrite arv staatilise ekraani korral ei ole iseenesest kõrvalekalle.

Ekraani värskendamise ajal mõõdetud sisend- ja väljundkaadrite, vahelejätmise põhjuste ja kodeerimisaja põhjal saate uurimise suunda kitsendada. Loendurite liigitus on vihje ning otsus tehakse koos tegeliku koormuse ja ühenduse konfiguratsiooniga. Vt: Kaadrite arvu ja kodeerimisaja tõlgendamine.

flowchart TB
    accTitle: Uurimise suuna kitsendamine kaadrite vahelejätmise põhjal
    accDescr: Ekraani värskendava toimingu ajal võrreldakse sisend- ja väljundkaadrite arvu ning kõrvutatakse vahelejätmise põhjuse loendureid töötluse, võrgu ja kuvamise koormusega.
    A["Võrdle kerimise ajal sisendit ja väljundit"] --> B["Kui väljundit on vähem, kontrolli vahelejätmist"]
    B --> C["Vaata põhjusepõhiseid loendureid"]
    C --> D["Kõrvuta kaugarvuti, võrgu ja kohaliku koormusega"]

Joonis 15: Võrrelge kerimise ajal sisendit ja väljundit ning kõrvutage vahelejätmise põhjust kaugarvuti, ühenduse ja kohaliku arvuti koormusega.

Ärge üldistage ekraanipildi edastuse kontseptuaalset joonist ega vanu materjale kõigile konfiguratsioonidele. Mõnes konfiguratsioonis edastatakse videot ja heli eraldi mehhanismiga. Kuna Graphics-loendurite materjal kirjeldab ka vanemaid konfiguratsioone, ärge tõlgendage seal toodud arve ühise spetsifikatsioonina, et „kõigi RDP-ühenduste maksimum on 30 fps“. Kontrollige enne kasutamist, millele funktsioonid ja arvud kehtivad. Vt: Ekraanipildi edastus ja töökoormus, Graphics-loendurite materjal.

Mõõtmistulemuste kehtivusulatus

Madalat arvu ei samastata sellega, et töö on mugav. Iga näitaja ulatust saate kontrollida juhistes viidatud Microsofti materjalidest.

Võrgu- ja GPU sätted

UDP ja GPU sätted valige vastavalt sellele, mida võrdlused ja mõõtmised näitasid. Kui kahtlus langeb võrguliiklusele, kontrollige esmalt ühendusviisi ja teed; kui kahtlus langeb ekraanitöötlusele, kontrollige esmalt, millises etapis GPU-d kasutatakse.

TCP, UDP ja ühendustee kontrollimine

Kui võrdlused ja mõõtmised viitavad võrguliiklusele, kontrollige koos administraatoriga kasutatavat klienti, ühendusteed ja rakenduvaid poliitikaid. Ka siis, kui sätteid on vaja muuta, tehke seda ainult heakskiidetud ulatuses ning pange kirja väärtused enne muudatust ja taastamise viis. Ärge keelake tulemüüri ega autentimist ja ärge avage RDP-porti otse internetti.

1. Kontrollige ühenduse teabe, toote diagnostikalogide ja administraatori liikluslogide abil tegelikku TCP/UDP kasutust ja teed.

   RDP kasutab sõltuvalt konfiguratsioonist ja võrgutingimustest TCP-d või UDP-d. Poliitikas „Select RDP transport protocols“ saab valida sätte, mis kasutab UDP-d või TCP-d, ja sätte, mis kasutab ainult TCP-d. Kuna UDP-ühenduse ebaõnnestumisel võidakse kasutada TCP-d, ei näita ainuüksi ühenduse õnnestumine, millist protokolli kasutatakse. Vt: RDP transpordi valik ja tagasilangemine.

2. Kõrvutage teed ja protokolli sümptomi ajaga ning võrrelge ainult vajalikke sätteid ükshaaval.

   Ärge muutke sätteid üldise eelduse põhjal, et „UDP väljalülitamine teeb kiiremaks“. Võrrelge, hoides VPN-i ja lüüsi tingimused, toimingu ja kuvatingimused samad, ning võtke mittevajalikud muudatused tagasi.

Kui protokoll ja tee on teada, saate muudatuse ja sümptomi seose kirja panna. Ainult TCP kasutamisele üleminek ei tee ühendust alati kiiremaks.

flowchart TB
    accTitle: Kontrollige ühendusviisi enne võrgusätete võrdlemist
    accDescr: Eristatakse tavalist otseühendust ning lüüsi või teenuse kaudu toimuvat ühendust, kontrollitakse tegelikku teed ja protokolli ning alles seejärel tehakse lubatud võrdlus.
    A["Kasutatav klient ja ühenduse konfiguratsioon"] --> B["Kontrolli tegelikku teed, TCP või UDP"]
    B --> C["Kõrvuta sümptomi ajaga"]
    C --> D["Võrdle ükshaaval ainult vajalikke sätteid"]

Joonis 16: Kontrollige kasutatavat ühendusviisi ja teed, kõrvutage neid sümptomiga ja võrrelge alles seejärel ainult vajalikke sätteid.

RDP Shortpath on Azure Virtual Desktopi mehhanism. See loob selle teenuse UDP-tee ning kasutab sõltuvalt konfiguratsioonist otseteed või releed. Kui teed ei õnnestu luua, minnakse tagasi TCP-põhisele ühendusele. Seda ei saa käsitleda samas sätete tabelis kui otseühendust ettevõtte arvutiga mstsc abil. Vt: RDP Shortpathi teed ja tagasilangemine.

flowchart TB
    accTitle: RDP Shortpathi teed ja tagasilangemine
    accDescr: Azure Virtual Desktopi RDP Shortpath proovib luua UDP-tee; kui see õnnestub, kasutatakse sõltuvalt konfiguratsioonist otseteed või releed, ja kui ei õnnestu, minnakse tagasi TCP-põhisele ühendusele.
    A["RDP Shortpath"] --> B{"UDP-tee"}
    B -->|"loodud"| C["Otsetee või relee"]
    B -->|"ei õnnestu"| D["Tagasi TCP-põhisele"]

Joonis 17: Kui RDP Shortpath ei suuda UDP-teed luua, minnakse tagasi TCP-põhisele ühendusele.

GPU kasutuse kontrollimine ekraanitöötluses

Tehke see kontroll siis, kui võrdlused ja mõõtmised viitavad ekraanitöötlusele. Kontrollige ekraanitöötluse mõõtmistulemusi ning toetatud OS-i, draiverit, poliitikaid ja klienti. Ärge muutke sätteid ainult sellepärast, et arvutis on GPU. Hankige kõigepealt administraatori heakskiit ja valmistage ette taastamise võimalus.

1. Eristage kaugarvuti rakenduse renderdamine, RDP kodeerimine ja kohalik dekodeerimine ning valige kahtlane etapp.

   Isegi kui GPU on olemas, ei pruugi kõik etapid seda kasutada. Ka Microsofti Azure Virtual Desktopi konfigureerimise materjalides seadistatakse ja kontrollitakse kaugseansi renderdamist ja kaadrite riistvaralist kodeerimist eraldi. Vt: GPU konfigureerimine ja kontrollimine renderdamiseks ja kodeerimiseks.

2. Kontrollige tegelikku kasutust asjaomase toote juhiste järgi ja mõõtke sama toimingut enne ja pärast vajalikku muudatust.

   Kui tihendamisaeg on pikk, uurige GPU kasutamist kodeerimisel. Kui rakendus ootab sisendijärjekorras, sihib kodeerimissätete muutmine vale kohta. Teksti loetavuse ja video sujuvuse puhul tehakse ka pildikvaliteedi, andmemahu ja töötluskoormuse valikud erinevalt. Vt: Erinevused töökoormuse järgi.

Nii saate lisaks GPU olemasolule kirja panna, kas GPU-d kasutati probleemses etapis ning kuidas muutusid sama toimingu koormus ja reageerimine. Muudatused, mis olukorda ei paranda, võtke pärast administraatoriga kooskõlastamist tagasi.

flowchart TB
    accTitle: GPU kasutuse kontrollimine etappide kaupa
    accDescr: Eristatakse kaugarvuti rakenduse renderdamine, RDP kodeerimine ja kohalik dekodeerimine ning kuna ka GPU olemasolul ei pruugi kõik etapid seda kasutada, kontrollitakse kasutust kahtlases etapis.
    A["Kaugarvuti rakenduse renderdamine"] --> B["RDP kodeerimine"]
    B --> C["Kohalik dekodeerimine"]
    C -.- D["Kontrolli GPU kasutust etappide kaupa"]

Joonis 18: Isegi kui GPU on olemas, ei pruugi renderdamine, kodeerimine ja dekodeerimine kõik GPU-d kasutada.

Taaskontroll ja üleandmine

Paranemist kinnitab see, et pärast muudatust saab sama toimingut takistusteta teha ning lisaks säilivad vajalik pildikvaliteet, seadmed ja tööfunktsioonid. Kõrvutage ka tulemust pärast algsete tingimuste taastamist. Kui taastumine oli vaid hetkeline, ärge tehke põhjust kindlaks, vaid pange kirja ka tipptunnid ja samaaegsed töötlused.

flowchart TB
    accTitle: Paranemise kontrollimise järjekord
    accDescr: Näitab, et lisaks sellele, kas sama toimingut saab pärast muudatust takistusteta teha, kontrollitakse vajaliku pildikvaliteedi, seadmete ja tööfunktsioonide säilimist, kõrvutatakse tulemust pärast algsete tingimuste taastamist ning hetkelise taastumise põhjal põhjust kindlaks ei tehta.
    A["Proovi pärast muudatust sama toimingut"] --> B["Kontrolli pildikvaliteeti, seadmeid ja funktsioone"]
    B --> C["Kõrvuta tulemusega pärast taastamist"]
    C -.- D["Hetkeline taastumine ei kinnita põhjust"]

Joonis 19: Lisaks sama toimingu tulemusele kõrvutage ka vajalikke funktsioone ja tulemust pärast taastamist.

Üleandmine lahendamata probleemi korral

Ka see, et olukord ei parane, probleem ei kordu või loendurid ei ole saadaval, on kasulik tulemus. Eristage tehtud võrdlused ja kontrollid, mida ei õnnestunud teha, ning andke uurimine järgmise märkme abil üle administraatorile või arendajale. Eemaldage jagatavatest logidest uurimiseks mittevajalik äriteave, näiteks kasutajanimed ja sihtarvutid.

Sümptomi tekkimise aeg ja ajavöönd:
Kaugarvuti OS, kasutatav klient ja versioon:
Otseühendus / VPN / RD Gateway / Azure Virtual Desktop vms:
Aeglane toiming ja rakendus, teiste rakenduste reageerimine samas seansis:
Kaugpoole eraldusvõime ja monitoride arv:
Samal ajal toimunud kopeerimine, printimine vms:
Ainsana muudetud tingimus ja tulemus pärast taastamist:
Kaugarvutis ja kohalikus arvutis täheldatud koormus või loendurid:

Lisage ka, kas tegelikku TCP/UDP kasutust õnnestus kontrollida, millised punktid jäid näiteks õiguste puudumise tõttu kontrollimata ja millised sätted on töö seisukohalt vastuvõetavad. Kui ütlete „Märkmikus saab tavapäraselt kirjutada, kuid fotode kerimisel kõik peatub“, mitte „ühendus on aeglane“, saab järgmine vastutaja uurida samadel tingimustel.

Kasutaja paneb kirja toimingu, millega probleem kordub, ja võrdluste tulemused, administraator kõrvutab ühendustee, jagatud hosti ja seansside logisid. Ainuüksi see, et ootamine toimub RDP kaudu, ei tähenda, et ootamist põhjustav töötlus on samuti RDP. Vt: Hosti ja taustasüsteemide rollijaotus.

Rakenduse arendaja logib eraldi sisendisündmuse vastuvõtmise, andmebaasi- ja failitöötluse alguse ja lõpu ning kajastamise kasutajaliideses. Kaalutakse ka disaini, mis ei lase rasket tööd UI-lõimele pidama jääda. Samas ei salvesta kaugarvuti töötluse lõpu logi kuvamise lõppu kohalikus arvutis. Vt: Töötluse eraldamine UI reageerimisvõime säilitamiseks.

Seotud artiklid

• Kuidas mõista Windowsi seansside eraldatust
• Windowsi 100% kettakasutuse põhjuse ohutu piiritlemine
• Miks „1 sekund jäänud“ ei lõpe?

Viited

Allpool on Microsoft Learni esmased allikad. Viidatud sisu kontrolliti 17. septembril 2026. Lugedes eristage iga toote rakendustingimusi ning pidage meeles, et need ei ole selle artikli jaoks tehtud mõõtmised.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. RTT eristamine viivitusest, mis ulatub ekraanipildi hõivamisest kaugarvutis kuni kuvamiseni kohalikus arvutis. Diagnostikafunktsioon ise on mõeldud Azure Virtual Desktopi jaoks.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. Ekraani sisu, eraldusvõime, kaadrite värskendamise, tihendamise ja vahemälu seos andmemahuga.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. Ekraani sisend- ja väljundkaadrite, vahelejätmise põhjuste ja kodeerimisaja kontrollimine. Kuna materjal sisaldab vanemate konfiguratsioonide kirjeldusi, ei üldistata arvulisi ülempiire kõigile RDP-ühendustele.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. Jagatud hosti koormus, liiklus kaugarvutist taustasüsteemidesse ja seadmete ümbersuunamise mõju.
• Microsoft Learn, Threading model. WPF-i UI-lõim ja Dispatcher ning töötluse eraldamine reageerimisvõime säilitamiseks.
• Microsoft Learn, mstsc. Kaugtöölaua laiuse ja kõrguse ning mitme monitori määramine.
• Microsoft Learn, Supported RDP properties. Töölaua eraldusvõime, dünaamilise eraldusvõime ja smart sizingu eristamine. Kontrollige toetatud kliente ja iga toote rakendustingimusi.
• Microsoft Learn, ping. Vastuse kontrollimine ICMP Echo abil ja suvandid.
• Microsoft Learn, Test-NetConnection. TCP-ühenduse kontrollimine ja väljundi tähendus.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. User Input Delay mõõtelõik, toetatud OS-id, eksemplarid ja maksimumväärtuse tähendus.
• Microsoft Learn, query session. Seansi teave ja teiste seansside päringuks vajalikud õigused.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. RDP kasutatava TCP/UDP valik ja tagasilangemine.
• Microsoft Learn, RDP Shortpath. Azure Virtual Desktopi UDP-tee ja käitumine, kui seda ei õnnestu luua.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. GPU konfigureerimine ja kontrollimine eraldi renderdamise ja kaadrite kodeerimise jaoks.

Seotud artiklid

Viimased samade siltidega artiklid. Nende abil saate teemasse süveneda.

Seotud teemad

Sellega lähedased teemalehed. Artiklist saate liikuda edasi seotud teenuste ja teiste artiklite juurde.

Teenused, millega see teema seondub

See artikkel seondub järgmiste teenuslehtedega. Alustage sobivaimast.

Korduma kippuvad küsimused

Küsimused, mida nõustamisel selle artikli teemal sageli esitatakse.

Kiirustest näitab mitusada Mbps, miks on sisestamine RDP-s siis aeglane?

Suurte andmemahtude edastamise kiirus ja aeg, mis kulub toimingule vastuse saamiseks, on eri asjad. Mõju avaldavad sisendi saatmine, kaugarvuti rakenduse töötlus, ekraanipildi tihendamine, edastus ja kuvamine kohalikus arvutis. Lisaks erineb ka võrgutee kiirustesti serveri ja RDP kaugarvuti puhul.

Teksti saab tavapäraselt sisestada, kuid ainult kerimine hakib. Kas see on ühenduse probleem?

Põhjust ei saa kitsendada ainult ühendusele. Kui ekraanivärskendusi tuleb rohkem, võib maha jääda kas kaugarvuti renderdamine ja tihendamine, võrguliiklus või kohalik dekodeerimine ja kuvamine. Muutke kaugpoole eraldusvõimet või monitoride arvu ükshaaval ja võrrelge ning vajaduse korral uurige renderdamisega seotud loendureid.

Kui ping on kiire, kas RDP võrguliiklus on siis korras?

Ainult selle põhjal seda otsustada ei saa. Ping mõõdab vastust ICMP-le, mitte RDP ekraanipildi edastust ega rakenduse töötlust. RD Gateway vms kasutavates konfiguratsioonides ei pruugi ka tee kattuda. Kui vastust ei tule, eristage ICMP blokeerimist ja seda, et RDP ise ei saa ühendust.

Kas User Input Delay on aeg klahvi vajutamisest märgi ilmumiseni?

Ei ole. See on loendur, mis mõõdab ooteaega sellest hetkest, kui sisend kaugarvutis järjekorda satub, kuni protsess selle välja võtab. See ei ole tajutav viivitus, mis hõlmaks võrgu edasi-tagasi liikumist, rakenduse töötlust pärast sisendi väljavõtmist ning ekraanipildi tihendamist, dekodeerimist ja kuvamist.

Kas RDP aeglase töö korral tuleks UDP keelata?

Me ei soovita seda üldiselt. Kõigepealt kontrollige tegelikku ühendusviisi, teed ja rakenduvaid poliitikaid. Võib juhtuda, et UDP-d ei saa kasutada ja ühendus on langenud tagasi TCP-le, ning ainult TCP kasutamisele üleminek ei tee ühendust alati kiiremaks. Võrrelge administraatori loal samadel tingimustel ja võtke mittevajalikud muudatused tagasi.

Autori profiil

Artikli autori profiilileht.

Go Komura

KomuraSoft LLC esindaja

Tegeleb peamiselt Windowsi tarkvara arenduse, tehnilise nõustamise ja veaotsinguga. Tugevus on projektid, kus on säilinud olemasolevaid lahendusi, ning raskesti jälgitavate põhjustega tõrgete uurimine.