Miksi RDP on hidas, vaikka yhteys on nopea? – Syötteen, renderöinnin ja tietoliikenteen erillinen tarkastelu

Nopeustesti näyttää satoja Mbps, mutta etätyöpöydässä merkit ilmestyvät pienellä viiveellä. Kun vierität kuvapitoista sivua, kuva tökkii. Liiketoimintasovellus pysähtyy muutamaksi sekunniksi vain, kun painat hakua. Mistä tällaista ”yhteys on nopea, mutta RDP on hidas” -tilannetta kannattaa alkaa selvittää?

RDP:n reagointi toimintoihin ei riipu pelkästään yhteyden siirtonopeudesta. Vaikka nopeustesti olisi nopea, odotusta voi syntyä tietoliikenteen edestakaisessa matkassa, etäkoneen sovelluksen syötteen odotuksessa, ruudun koodauksessa tai paikallisen koneen dekoodauksessa ja näyttämisessä. Erota ensin, ”mikä toiminto on hidas”, ja vertaa samaa toimintoa muuttaen yhtä ehtoa kerrallaan. Rajaa selvityskohdetta vertailuilla ja mittauksilla ja valitse UDP- ja GPU-asetukset niiden tulosten mukaan. Katso: Yhteyden laadun mittausvälit, Istuntoisännän suorituskykyyn vaikuttavat tekijät.

Kun selvityskohde on vasta rajattu, perimmäinen syy ei ole vielä varmistunut. Vaikka näyttötarkkuuden laskeminen parantaisi tilannetta, tietoliikenteen lisäksi myös molempien päiden ruudun käsittely muuttuu, joten emme väitä varmasti, että ”syy oli yhteydessä”. Kirjaa tulokset ja erottele mitatut ja mittaamattomat välit.

Tässä artikkelissa erotellaan yhteyden muodostamisen jälkeiset kirjoittamisen, vierityksen ja sovelluksen vasteen ongelmat. Vaikka oireet olisivat samankaltaisia, syitä voi olla useampi kuin yksi. Tapauksia, joissa ”kirjautumisnäkymän ilmestyminen kestää kauan” tai ”kaikki pysähtyy todennukseen”, käsitellään erillisenä ongelmana, jota selvitetään yhteyden muodostamisen ja todennuksen lokien avulla.

Artikkeli on tarkoitettu pääasiassa käyttäjille ja järjestelmänvalvojille, jotka muodostavat yhteyden Windowsin ”Etätyöpöytäyhteys”-sovelluksella (mstsc) Windows 11:een tai Windows Serveriin. Komentoesimerkit on tarkoitettu Windows PowerShell 5.1:lle. Oletuksena on, että samaa toimintoa voi toistaa jo muodostetussa istunnossa.

Suorassa yhteydessä, VPN:ssä, RD Gatewayssa ja Azure Virtual Desktopissa reitti, käytettävissä olevat diagnostiikkatiedot ja asetusten soveltamiskohde eroavat toisistaan. TCP 3389 -tarkistusesimerkki koskee vain sallittua suoraa yhteyttä RDP-isäntään, joka käyttää vakioporttia. Azure Virtual Desktopin aineistoissa kuvattuja diagnostiikkatoimintoja ja GPU-asetuksia ei sovelleta sellaisenaan tavallisiin yrityksen tietokoneisiin.

Yrityksen laitteilla selvitys tehdään vain järjestelmänvalvojan sallimissa rajoissa. Tunnista jaetulla isännällä oma istuntosi ja kohdeprosessi, ja jos tarvitset muiden käyttäjien tietoja, pyydä niitä järjestelmänvalvojalta. Suorituskykylaskureiden saatavuus, näyttönimet ja tarvittavat oikeudet tarkistetaan ympäristökohtaisesti.

Tässä esitetyt tarkistustavat perustuvat virallisiin aineistoihin. Ne eivät ole mittausraportti vian toistamisesta ja korjaamisesta tietyllä laitteella. Lukuesimerkit esitetään erikseen merkittyinä havainnollistavina oletuksina.

Toimintaperiaatteen voi lukea järjestyksessä seuraavasta osiosta ”Siirtonopeus ja kiertoaika” alkaen. Jos haluat aloittaa oireesta, siirry osioon ”Ensimmäinen vertailu oireen perusteella”. Toimenpideohjeet ovat osioissa ”Ehtojen vertailu yksi kerrallaan” ja ”Odotuskohdan mittaaminen”.

Kaaviossa yhtenäinen viiva kuvaa suhdetta, joka pätee aina, ja katkoviiva ehdollista suhdetta (ehdot on kuvattu kunkin suhteen kohdalla yksityiskohtasivulla). Suhteiden täydellinen luettelo (yhteensä 7, todisteineen ja varmuustasoineen) sekä keskeisten käsitteiden määritelmät on koottu tietokartan yksityiskohtasivulle (japaniksi). Data: JSON-LD / Turtle

Siirtonopeus ja kiertoaika

RDP (Remote Desktop Protocol) on protokolla, jolla paikallinen laite ja etäkone vaihtavat syötteitä, ruututietoja ja muita tietoja. Ruudun ja syötteen lisäksi se välittää myös laitteiden uudelleenohjauksen, tulostuksen ja muita tietoja. Katso: RDP:n siirtämät tiedot.

Yhteyden siirtonopeus kertoo, kuinka paljon dataa voidaan siirtää sekunnissa. Nopeustestin ”500 Mbps” on juuri tätä määrää kuvaava luku. Se ei kerro aikaa, joka kuluu toiminnosta vastauksen saapumiseen. Katso: RDP:n kaistanleveysvaatimukset.

flowchart TB
    accTitle: Mitä nopeustestin luku kertoo
    accDescr: Nopeustestin 500 Mbps kuvaa sekunnissa siirrettävän datan määrää, ja se on eri luku kuin aika, joka kuluu toiminnosta vastauksen saapumiseen.
    A["Nopeustesti: 500 Mbps"] --> B["Sekunnissa siirtyvä datamäärä"]
    B -.->|"eri luku"| C["Aika vastauksen saapumiseen"]

Kuva 1: Nopeustestin luku kertoo siirrettävän määrän, ei aikaa vastauksen saapumiseen.

Kiertoaika (RTT) on aika, jossa tieto kulkee vastapuolelle ja takaisin. Siirtonopeuden kasvattamisen ja kiertoajan lyhentämisen ero muistuttaa eroa tien kaistojen lisäämisen ja määränpään etäisyyden lyhentämisen välillä. Vaikka kyky siirtää suuria tiedostomääriä kasvaa, toiminnon vastauksen odotus säilyy, jos kiertoaika pysyy samana. Katso: RTT ja ruudun näyttämisen viive.

flowchart TB
    accTitle: Siirtonopeus ja kiertoaika tievertauksena
    accDescr: Kaavio vertaa siirtonopeuden kasvattamista tien kaistojen lisäämiseen ja kiertoajan lyhentämistä määränpään etäisyyden lyhentämiseen.
    A["Kasvata siirtonopeutta"] -->|"tiellä tämä on"| B["Lisää kaistoja"]
    B ~~~ C["Lyhennä kiertoaikaa"]
    C -->|"tiellä tämä on"| D["Lyhennä etäisyyttä"]

Kuva 2: Kaistojen lisääminen ei lyhennä matkaa määränpäähän.

Kunnes yhden merkin tulos palaa

Kuvitellaan, että kirjoitat yhden merkin etäkoneen Muistioon. Muistio toimii etäkoneella. Jos havainnollistuksen vuoksi oletetaan, että toiminnon perille meno kestää 50 millisekuntia ja tuloksena syntyvän ruututiedon paluu 50 millisekuntia, tietoliikenteeseen kuluu yhteensä 100 millisekuntia eli 0,1 sekuntia. Molempien päiden käsittelyaika on jätetty tästä esimerkistä pois.

flowchart TB
    accTitle: Esimerkki tietoliikenteen ajasta, kunnes yhden merkin tulos palaa
    accDescr: Havainnollistava esimerkki, jossa meno- ja paluumatkan kestoksi oletetaan kummallekin 50 millisekuntia. Molempien päiden käsittelyaikaa ei ole laskettu mukaan, eikä kaavio kuvaa pakettien määrää näppäintä kohden.
    A["Kirjoitat paikallisesti yhden merkin"] -->|"meno: 50 ms"| B["Etäkone vastaanottaa syötteen"]
    B --> C["Lähettää syötteen mukaisen ruudun"]
    C -->|"paluu: 50 ms"| D["Tulos saapuu paikalliselle koneelle"]

Kuva 3: Jos meno kestää oletettavasti 50 millisekuntia ja paluu 50 millisekuntia, pelkkään tietoliikenteeseen kuluu 0,1 sekuntia. Kyse ei ole mitatusta arvosta.

Vaikka yhteyden siirtokyky kasvaisi, nämä 0,1 sekuntia säilyvät, jos kiertoaika ei muutu. Kuva 3 on käsitekaavio käsittelyn ymmärtämiseksi. Se ei tarkoita, että jokaista näppäintä kohden lähetettäisiin oma erillinen edestakainen paketti. Nopeustestin palvelimelle ja RDP-etäkoneelle kulkevat reitit myös eroavat, joten huomioon on otettava VPN, yhdyskäytävä, etäkoneen lähetyssuunta ja matkan varrella oleva ruuhka. Katso: RTT:n tulkinta, Verkon ja isännän suorituskyky.

Ruudun muodostaminen ja toimittaminen

Toiminnon vasteviiveellä tarkoitetaan tässä odotusta siitä, kun teet toiminnon paikallisella koneella, siihen, kun tulos näkyy. Siihen vaikuttavat RTT:n lisäksi sovelluksen käsittely sekä ruudun muodostaminen ja toimittaminen. Se erotetaan myös viiveestä, joka koskee pelkkää ruudun siirtoväliä. Katso: Mittausväli ruudun kaappauksesta näyttämiseen.

Kun syöte saapuu paikalliselta koneelta etäkoneelle, etäkoneen sovellus käsittelee syötteen ja päivittää ruudun, koodattu ruututieto siirretään yhteyden yli ja paikallinen kone dekoodaa ja näyttää sen. Myös ennen tietoliikennettä ja sen jälkeen on työtä, jonka eri tietokoneet hoitavat. Katso: Käsittely ruudun kaappauksesta näyttämiseen.

flowchart TB
    accTitle: Ruudun käsittelyä on myös ennen yhteyttä ja sen jälkeen
    accDescr: Kulku, jossa paikallinen syöte saapuu etäkoneelle, etäkoneen sovellus käsittelee sen, ruutu muodostetaan ja pakataan, ja yhteyden yli tuotu ruututieto palautetaan paikallisella koneella näytettävään muotoon ja näytetään.
    I["Paikallinen: syötät toiminnon"] --> J["Yhteys: vie syötteen"]
    J --> K["Etäkone: sovellus käsittelee"]
    K --> A["Etäkone: muodostaa ja pakkaa ruudun"]
    A --> B["Yhteys: vie ruututiedon"]
    B --> C["Paikallinen: palauttaa näytettäväksi"]
    C --> D["Näytetään paikallisella ruudulla"]

Kuva 4: Etäkone käsittelee ja pakkaa, yhteys siirtää ja paikallinen kone palauttaa näytettäväksi. Jokainen työ tehdään eri paikassa.

Koodauksella tarkoitetaan tässä artikkelissa käsittelyä, joka muuntaa ja pakkaa ruudun etäkoneella helposti lähetettävään muotoon. Yhteyden kautta tapahtuvan siirron lisäksi se vie etäkoneella käsittelyaikaa. Katso: Koodausaika etäkoneella.

Dekoodauksella tarkoitetaan tässä artikkelissa käsittelyä, joka palauttaa saapuneen ruututiedon paikallisella koneella näytettävään muotoon. Se erotetaan salauksen purkamisesta. Katso: Dekoodaus- ja näyttöaika paikallisella koneella.

Jos pakkaus etäkoneella vie aikaa, lähetyksen valmistelua joudutaan odottamaan, vaikka yhteys olisi vapaa. Vaikka tieto olisi perillä, päivitys viivästyy, jos paikallinen dekoodaus tai näyttäminen ei pysy tahdissa. Ei voi olettaa, että ”työpaikan kone on tehokas, joten paikallisella laitteella ei ole väliä”. Yhteyden kapasiteettivara ja sen molempien päiden käsittelyvara ovat eri asioita. Katso: Ruudun käsittelyn suorituskykylaskurit.

flowchart TB
    accTitle: Viive, kun molempien päiden käsittely ei pysy tahdissa
    accDescr: Kaavio näyttää, että jos pakkaus etäkoneella vie aikaa, lähetyksen valmistelua odotetaan vapaallakin yhteydellä, ja jos paikallinen dekoodaus tai näyttäminen ei pysy tahdissa, päivitys viivästyy, vaikka tieto olisi perillä.
    A["Pakkaus etäkoneella vie aikaa"] --> B["Lähetys odottaa vapaallakin yhteydellä"]
    B ~~~ C["Paikallinen dekoodaus jää jälkeen"]
    C --> D["Päivitys viivästyy, vaikka tieto on perillä"]

Kuva 5: Vaikka yhteydellä olisi kapasiteettia, ruudunpäivitys viivästyy, jos molempien päiden käsittely ei pysy tahdissa.

Tekstinsyötön ja vierityksen ero

Kun lisäät Muistioon yhden merkin, vain pieni osa ruudusta muuttuu. Kun vierität kuvapitoista sivua, laaja osa näkymästä muuttuu yhä uudelleen. RDP pienentää tiedonsiirron määrää siirtämällä muuttuneet osat sekä käyttämällä sisältöön sopivaa pakkausta ja välimuistia. Se ei lähetä joka kerta koko ruutua pakkaamattomana. Työmäärä riippuu ruudun sisällöstä ja päivitystiheydestä. Katso: Ruudun sisällön ja kaistanleveyden suhde.

flowchart TB
    accTitle: Tekstinsyötössä ja vierityksessä muuttuva ruututyön määrä
    accDescr: Pieni merkkimuutos ja laajan alueen jatkuva päivitys eroavat ruudun muodostamisen ja lähettämisen työn luonteelta.
    A{"Ruudun muutos"} -->|"yksi merkki lisää"| B["Pieni alue"]
    A -->|"vieritys"| D["Laaja alue jatkuvasti"]
    B --> E["Pakkaus ja siirto muutoksen mukaan"]
    D --> E

Kuva 6: Samassakin yhteydessä työmäärä on eri, kun lisätään yksi merkki ja kun laaja alue liikkuu jatkuvasti.

Vaikka staattinen asiakirja olisi kevyt, ruudun siirron kapasiteetti voi loppua vierityksen aikana. Kun etäpään näyttötarkkuutta tai näyttöjen määrää kasvatetaan, myös käsiteltävä ruutu kasvaa. Näyttötarkkuutta laskemalla tehtävä vertailu on koe, jolla selvitetään, palaako liike sujuvaksi, kun ruudun muodostamisen ja lähettämisen työtä vähennetään. Se ei ole laskelma, joka määrittäisi tiedonsiirron määrän pelkästä pikselimäärästä. Katso: Näyttötarkkuuden, ruudunpäivityksen ja pakkauksen vaikutus.

Sovelluksen odotukset

Jos vain liiketoimintasovelluksen haku pysähtyy muutamaksi sekunniksi, mutta samassa istunnossa Muistioon voi kirjoittaa normaalisti, tarkista, mitä sovellus odottaa. Etäkoneen sovellus voi puolestaan lähettää haun toiseen tietokantaan tai lukea tiedoston jaetusta kansiosta ja odottaa vastausta. Tämä on eri reitti kuin paikallisen koneen ja etäkoneen välinen RDP-liikenne. Katso: Liikenne etäkoneelta taustajärjestelmiin.

flowchart TB
    accTitle: Myös RDP:n takana on viestintäosapuolia
    accDescr: Kaavio näyttää tapauksen, jossa paikallisen laitteen ja etäkoneen välisen liikenteen lisäksi etäkoneen sovellus odottaa liiketoimintapalvelimen vastausta.
    A["Paikallinen laite"] -->|"RDP"| B["Etäkoneen liiketoimintasovellus"]
    B -->|"haku, tiedostopyyntö"| C["Tietokanta, jaettu kansio"]
    C -->|"odotettu vastaus"| B

Kuva 7: RDP:n takana oleva liiketoimintasovellus voi puolestaan odottaa toisen palvelimen vastausta.

Kun ruudusta ja syötteestä vastaava käsittely on varattuna pitkällä työllä, seuraava syöte ja ruudunpäivitys viivästyvät. Esimerkiksi WPF:ssä reagointikyky heikkenee, jos UI-säie on pitkään varattuna. Pelkkä koko CPU:n matala käyttöaste ei sulje pois tietyn UI-säikeen odotusta. Katso: Dispatcher ja UI-säie.

flowchart TB
    accTitle: Ruudusta ja syötteestä vastaava käsittely tukkeutuu
    accDescr: Kaavio näyttää, että kun ruudusta ja syötteestä vastaava käsittely on varattuna pitkällä työllä, seuraava syöte ja ruudunpäivitys viivästyvät, eikä pelkkä koko CPU:n matala käyttöaste sulje tätä odotusta pois.
    A["Ruudun ja syötteen käsittely"] --> B["Varattuna pitkällä työllä"]
    B --> C["Seuraava syöte ja päivitys viivästyvät"]
    C -.- D["Matala koko CPU ei sulje pois"]

Kuva 8: UI-säikeen odotusta ei voi sulkea pois pelkän koko CPU:n käyttöasteen perusteella.

Ensimmäinen vertailu oireen perusteella

Siirrettävä määrä, vastauksen odotusaika sekä ruudun muodostamiseen ja näyttämiseen kuluva aika ovat eri asioita. Kun tämä ero pidetään mielessä, ”RDP on hidas” -havaintoa ei tarvitse kuitata yhdellä syyllä, vaan selvittämisen voi aloittaa juuri nyt hitaasta toiminnosta.

flowchart TB
    accTitle: Erota kolme asiaa ennen selvittämistä
    accDescr: Kaavio näyttää, että ”RDP on hidas” -havaintoa ei kuitata yhdellä syyllä, vaan siirrettävä määrä, vastauksen odotusaika sekä ruudun muodostamiseen ja näyttämiseen kuluva aika erotetaan ja selvitys aloitetaan juuri nyt hitaasta toiminnosta.
    A["”RDP on hidas”"] --> S
    subgraph S["Tarkastele erikseen"]
    direction TB
    B["Siirrettävä määrä"] ~~~ C["Vastauksen odotusaika"]
    C ~~~ D["Ruudun muodostus- ja näyttöaika"]
    end
    S --> E["Selvitä nyt hidas toiminto"]

Kuva 9: Kun siirrettävä määrä, vastauksen odotusaika sekä ruudun muodostamiseen ja näyttämiseen kuluva aika erotetaan, selvityksen voi aloittaa juuri nyt hitaasta toiminnosta.

Erottelun tavoitteena on rajata kohta, josta hitautta selvitetään. Tavoitteena ei ole muuttaa asetuksia kerralla ja saada sattumalta nopeampi tulos. Kun hyödynnät eroja, kuten ”Muistio toimii, mutta vain haku pysähtyy” tai ”kirjoittaminen on normaalia, mutta vain vieritys on hidasta”, voit valita selvityksen lähtökohdan jo ennen tietoliikenneasetusten muuttamista.

Seuraava taulukko on selvityksen lähtökohta. Se ei ole taulukko syyn määrittämiseen. Vertaa ensin toimintoja samassa istunnossa ja muuta vasta sitten tarvittaessa laitetta, reittiä tai näyttöehtoja.

Merkit viivästyvät useassa sovelluksessa

Jos merkit viivästyvät samassa istunnossa useassa sovelluksessa, vertaa samaa toimintoa myös toiselta laitteelta tai toista sallittua reittiä pitkin. Vertaa kiertoaikaa, etäkoneen syötteen odotusta ja etäkoneen kokonaiskuormitusta keskenään äläkä määritä syytä yhden luvun perusteella.

Vain vieritys nykii

Vaikka kirjoittaminen olisi normaalia, kuvapitoisen sivun vierittäminen aiheuttaa jatkuvia laajan alueen ruudunpäivityksiä. Muuta etäpään näyttötarkkuutta tai näyttöjen määrää yksi kerrallaan ja vertaa samalla sivulla. Jos tilanne paranee, seuraavat selvityskohteet ovat pakkaus etäkoneella, ruudun siirto ja paikallinen dekoodaus. Pelkän näyttötarkkuuden perusteella ei selviä, mikä näistä kolmesta on syynä. Katso: Ruudun sisällöstä ja näyttötarkkuudesta johtuva kuormitus.

Vain yksi sovellus jumittuu

Jos vain se liiketoimintasovellus pysähtyy, jossa painoit hakua, vertaa, vastaavatko Muistio tai muut sovellukset samassa istunnossa. Jos muut sovellukset toimivat, selvitä ensin kyseisen sovelluksen käsittely, levy sekä tietokantaan ja jaettuun kansioon kohdistuvat pyynnöt. Se, että työskentelet RDP:n kautta, ja se, että odotuksen syy on RDP-liikenne, ovat eri asioita. Katso: Sovelluksen ja taustajärjestelmien suorituskykytekijät.

Kaikilla hidasta vain käyttäjämäärän kasvaessa

Jos usean käyttäjän työ hidastuu samaan aikaan, kysy järjestelmänvalvojalta muiden istuntojen tilannetta. Vertaa jaetun isännän CPU:n, muistin ja tallennustilan sekä jaetun yhteyden kuormitusta oireen ajankohtaan. Älä käytä muiden käyttäjien tietoja tai käsittelyjä ilman lupaa äläkä pysäytä heidän töitään. Katso: Jaetun isännän resurssit ja käyttäjämäärä.

Hidastuminen kopioinnin tai tulostuksen aikana

Jos ongelma osuu samaan aikaan kuin aloittamasi kopiointi tai tulostus, keskeytä vertailun ajaksi vain ne siirrot, joiden keskeyttäminen on sallittua. Kirjaa, palautuuko tilanne keskeytyksen jälkeen ja hidastuuko työ taas jatkamisen jälkeen, ja selvitä kilpailu muun kuin ruutuliikenteen ja laitteiden uudelleenohjauksen kanssa. Älä tee vertailua, jossa työn kannalta tarpeelliset laitteet poistetaan käytöstä kerralla. Katso: Laitteiden uudelleenohjauksen vaikutus.

Ehtojen vertailu yksi kerrallaan

Kaikkia asetuksia ei tarvitse muuttaa järjestyksessä. Luo ensin vertailukohta ja valitse vain oireeseen sopivat tarkistukset. Tallenna työsi ennen asetusten muuttamista ja uudelleen yhdistämistä ja kirjaa alkuperäiset arvot sekä niiden palautustapa. Jos tarvittavia oikeuksia tai toimintoja ei ole, älä ota niitä väkisin käyttöön, vaan siirrä asia järjestelmänvalvojalle.

Paikallinen käyttö ja RDP:n kautta tapahtuva käyttö eivät välttämättä tapahdu samoissa olosuhteissa. Se, että kaikki toimii nopeasti etäkoneen omalla näytöllä, on hyödyllinen tieto, mutta istunto ja renderöintiolosuhteet voivat erota. Yhtenäistä käyttäjä, data ja sovelluksen tila, äläkä rajaa syytä yhteyteen pelkästään siksi, että ”koneen omalla näytöllä on nopeaa”.

Saman toiminnon vertailu

Valmistele sama käyttäjä, sama data ja sama toiminto. Tarkista jaetulla isännällä oma istuntosi äläkä pysäytä muiden käyttäjien sovelluksia tai käsittelyjä. Myös toista laitetta tai toista reittiä käytetään vain järjestelmänvalvojan sallimissa rajoissa.

1. Toista hidas toiminto alkuperäisillä asetuksilla ja kirjaa ajankohta ja oire.

   Kirjoita Muistioon samassa etäistunnossa, jossa ongelmallinen sovellus toimii, suunnilleen saman verran tekstiä. Erota, koskeeko ongelma vain yhtä sovellusta vai koko istuntoa.

2. Tarkista etäkoneen ja paikallisen koneen kuormitus samana ajanjaksona.

   Tarkastele Tehtävienhallinnassa etäkoneella kohdesovelluksen CPU:n, muistin ja levyn käyttöä ja paikallisella koneella RDP-asiakasohjelman kuormitusta. Tarkista koko CPU:n arvon lisäksi myös kohdeprosessi. Katso: Mitä kuormitusta tutkittaessa tarkastellaan.

3. Muuta vain yhtä ehtoa – laitetta, sallittua reittiä tai näyttöehtoja – ja toista sama toiminto.

   Jos vertailussa muuttuu samalla myös etäkoneen tai sovelluksen tila, kirjaa myös tämä ero. Älä tulkitse tulosta, jossa useampi ehto muuttui, yhden ehdon vaikutukseksi.

4. Palauta alkuperäiset ehdot ja tarkista sama toiminto uudelleen.

   Jos työ pysyy nopeana palauttamisen jälkeenkin, syynä voi olla esimerkiksi tilapäinen kuormituksen muutos. Älä päättele varmasti, että muutos auttoi, vaan kirjaa ehdot, joilla oire toistuu.

Näin saat koottua tulokset alkuperäisestä tilasta, muutoksen jälkeen ja palautuksen jälkeen ja voit verrata, mitkä ehdot ja oireet vastaavat toisiaan. Tilannetta parantanut ehto on selvityksen vihje, eikä se yksinään todista perimmäistä syytä.

flowchart TB
    accTitle: Kerralla muutettavien ehtojen rajaaminen
    accDescr: Kulku, jossa valitaan alkuperäisessä tilassa toistuva toiminto, muutetaan vertailua varten vain yhtä ehtoa ja tarkistetaan myös palautuksen jälkeinen tulos.
    A["Sama toiminto alkuasetuksilla"] --> B["Muuta vain yhtä ehtoa"]
    B --> C["Toista sama toiminto"]
    C --> D["Palauta ja tarkista uudelleen"]
    D --> E["Kirjaa parantanut ehto"]

Kuva 10: Toista sama toiminto alkuperäisessä tilassa, muutoksen jälkeen ja palautuksen jälkeen ja kirjaa muuttunut ehto.

Etäpään näyttötarkkuuden vertailu

Tee tämä vertailu, kun ruudunpäivitys on raskasta, esimerkiksi vieritettäessä. Kirjaa näyttötarkkuus ja näyttöjen määrä ennen muutosta, tallenna työsi ja muodosta yhteys sitten uudelleen. Älä jätä pysyvään käyttöön asetusta, joka heikentää työn kannalta tarpeellista näkymää tai tekstin luettavuutta.

1. Muuta vain toista: näyttöjen määrää tai näyttötarkkuutta.

   mstsc:ssä voit verrata ennen yhteyden muodostamista ”Näyttö”-välilehden asetuksilla tai määrittämällä leveyden ja korkeuden. Katso: Näytön määrittäminen mstsc:ssä.

2. Varmista, että etätyöpöydän todellinen koko muuttui, ja vieritä samaa sivua.

   Jos vain pienennät paikallista ikkunaa, suurta työpöytää saatetaan ainoastaan näyttää pienennettynä. Erota dynaaminen näyttötarkkuus ja smart sizing ja tarkista käyttämäsi asiakasohjelman tukiehdot. Katso: Työpöydän näyttötarkkuus ja skaalaus.

3. Palauta alkuperäiset asetukset, toista sama toiminto ja vertaa molempien päiden kuormitusta ja ruudun liikettä.

   Jos muutit kerralla sekä matalamman näyttötarkkuuden että yhden näytön, vertailu jää karkeaksi. Jos tilanne paranee, palauta ne yksi kerrallaan ja erota niiden vaikutukset.

Jos tilanne paranee, vihje löytyy ruudun käsittelyn ja ruudun siirron alueelta. Tarkkuudessa 3840×2160 on nelinkertainen määrä pikseleitä tarkkuuteen 1920×1080 verrattuna, mutta tiedonsiirron määrä ei aina nelinkertaistu. Se riippuu muuttuneista osista ja pakkauksesta, ja näyttötarkkuuden muutos vaikuttaa myös molempien päiden käsittelyyn. Katso: Pikselimäärän ja tiedonsiirron määrän suhde, Ruudun käsittelyn tarkistaminen.

flowchart TB
    accTitle: Mitä näyttötarkkuutta laskemalla tehty vertailu kertoo
    accDescr: Etäpään näyttötarkkuuden laskeminen voi muuttaa sekä ruudun käsittelyn että siirron kuormitusta, joten pelkän parannuksen perusteella syytä ei voi rajata yhteyteen.
    A["Laske etäpään näyttötarkkuutta"] --> S
    subgraph S["Muuttuva käsittely"]
    direction TB
    B["Etäkoneen ruudun käsittely"] ~~~ C["Lähetettävän tiedon määrä"]
    C ~~~ D["Paikallinen näytön käsittely"]
    end

Kuva 11: Näyttötarkkuuden muutos on vertailu, joka vaikuttaa yhteyden lisäksi myös etäkoneen ja paikallisen koneen ruudun käsittelyyn.

Kopioinnin ja tulostuksen vertaaminen oireisiin

Keskeytä tilapäisesti vain käsittelyt, joiden keskeyttäminen on sallittua, kuten itse aloittamasi siirrot. Älä pysäytä yrityksen varmuuskopiointi- tai tietoturvakäsittelyjä äläkä muiden käyttäjien töitä. Älä poista käytöstä kerralla työn kannalta tarpeellisten ääni- ja syöttölaitteiden uudelleenohjausta.

1. Kirjaa sama toiminto ja kuormitus ennen kopioinnin, pilvisynkronoinnin tai tulostuksen alkua ja niiden aikana.

   RDP:n kautta kulkee ruudun lisäksi myös esimerkiksi asemien ja tulostimien tietoja. Uudelleenohjaus, jolla paikallisia laitteita käytetään etäkoneella, voi käytön aikana lisätä tietoliikenne- ja käsittelykuormitusta. Katso: Laitteiden uudelleenohjauksen vaikutus.

2. Keskeytä kyseinen siirto tilapäisesti sallituissa rajoissa ja tarkista sama toiminto uudelleen.

   Jos voit jatkaa siirtoa vertailun vuoksi, kirjaa myös jatkamisen jälkeinen oire. Myös tarpeettoman laitteiden uudelleenohjauksen kokeilussa muuta asetuksia yksi kerrallaan ja varmista, että alkuperäiset asetukset voidaan palauttaa.

Näin voit arvioida, vastaavatko siirron alku ja ongelma sekä keskeytys ja palautuminen toisiaan. Jos vastaavuus näkyy, vertaa muun kuin ruutuliikenteen ja jaettujen resurssien kuormitusta järjestelmänvalvojan lokeihin.

flowchart TB
    accTitle: Ongelmaa edeltävä ja seuraava tila samalla aikajanalla
    accDescr: Ennen siirtoa, siirron aikana ja keskeytyksen jälkeen kirjataan sama toiminto ja kuormitus ja verrataan ongelman ja työn yhteyttä.
    A["Toiminto ja kuormitus ennen siirtoa"] --> B["Toiminto ja kuormitus siirron aikana"]
    B --> C["Toiminto ja kuormitus keskeytyksen jälkeen"]
    C --> D["Vastaavatko ongelma ja palautuminen"]

Kuva 12: Tarkastele, miten saman toiminnon hitaus ja kuormitus muuttuvat ennen siirtoa, sen aikana ja keskeytyksen jälkeen.

Odotuskohdan mittaaminen

Paikalliselta koneelta tutkitaan tietoliikenteen kiertoaikaa ja TCP-yhteyttä, etäkoneella syötejonon odotusta ja ruudunpäivitystä. Koska jokainen luku mittaa vain rajattua väliä, lue tuloksia yhdessä osion ”Mittaustulosten pätevyysalue” taulukon kanssa.

ICMP:n ja TCP-yhteyden tarkistaminen

Suorita tarkistus paikallisella Windows-laitteella. Se on tarkoitettu vain kokoonpanoihin, joissa yhteys muodostetaan yrityksen lähiverkossa tai sallitun VPN:n kautta suoraan RDP-isäntään, joka käyttää vakioporttia TCP 3389. RD Gatewayn tai Azure Virtual Desktopin kautta kulkevissa yhteyksissä ja mukautettua porttia käyttävissä kokoonpanoissa sovi tarkistuskohteesta järjestelmänvalvojan kanssa. Portteja ei avata eikä palomuuria muuteta.

1. Syötä sallittu etäkone ja kirjaa ICMP-vastauksen ja TCP-yhteyden tulokset.

   $target = Read-Host 'Selvitettäväksi sallitun RDP-isännän nimi tai IP-osoite'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'Määritä etäkone.'
   }
       
   # Tarkastele ICMP-vasteaikaa useita kertoja. Pelkkä epäonnistuminen ei tarkoita, että RDP-yhteys ei toimi.
   ping.exe -n 20 $target
       
   # Tarkistus vain kokoonpanolle, jossa yhteys muodostetaan suoraan vakioporttiin TCP 3389.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. Vertaa hitaan ajanjakson ja normaalitilanteen tuloksia oireen ajankohtaan ja todelliseen yhteysreittiin.

   20 kertaa suoritettu ping on lyhyt havainto. Kirjaa arvojen vaihtelu ja vastaamatta jääneet pyynnöt, mutta huomaa, että ICMP voi olla estetty. Älä sulje pois ajoittaisia katkoja pelkän keskiarvon perusteella, vaan käytä yhteystietoja ja järjestelmänvalvojan liikennelokeja. Katso: Mitä ping mittaa.

TcpTestSucceeded: True tarkoittaa, että TCP-yhteys määritettyyn porttiin onnistui. Se ei mittaa kaistanleveyttä, UDP:tä, todennuksen jälkeisiä toimintoja eikä ruudun sujuvuutta. Cmdletissä Test-NetConnection ei ole UDP:n tarkistamiseen tarkoitettua valitsinta -UDP. Katso: Test-NetConnectionin syntaksi ja tulokset.

Arvioi reittien ja palvelujen erot huomioiden. RD Gatewayn kaltaisissa ratkaisuissa isäntään kulkevan ICMP:n ja suoran TCP-yhteyden reitti ei välttämättä ole sama kuin todellinen RDP-reitti. Azure Virtual Desktopissa on käytettävissä yhteyskohtainen RTT ja kaistanleveyden arvio, mutta tämä diagnostiikkatoiminto on tarkoitettu kyseiselle palvelulle. Älä sulje pois lyhyitä katkoja pelkän keskiarvon perusteella. Katso: Azure Virtual Desktopin yhteyden laatulokit.

flowchart TB
    accTitle: Tarkistettu reitti ja todellinen RDP-reitti
    accDescr: RD Gatewayn kaltaisia ratkaisuja käyttävissä kokoonpanoissa paikalliselta koneelta isäntään kulkevan ICMP:n ja suoran TCP-yhteyden reitti ei välttämättä ole sama kuin todellinen RDP-reitti.
    A["Paikallinen laite"] -->|"ICMP, suora TCP"| C["RDP-isäntä"]
    A -->|"todellinen RDP"| B["RD Gateway tms."]
    B --> C

Kuva 13: Isäntään kulkeva ICMP ja suora TCP-yhteys sekä todellinen RDP eivät välttämättä käytä samaa reittiä.

Syötejonon odotuksen mittaaminen

User Input Delay mittaa odotusta siitä, kun syöte siirtyy etäkoneella jonoon, siihen, kun prosessi ottaa sen jonosta. Se ei ole kokonaisaika näppäimen painamisesta merkin näkymiseen. Katso: User Input Delayn määritelmä.

Tutki tätä etäkoneen etäistunnossa. Microsoftin tukiehdot ovat Windows 10:n versio 1809 tai uudempi ja Windows Server 2019 tai uudempi. Näissä järjestelmissä käyttöönottoon ei tarvita rekisterimerkinnän lisäämistä. Tarkista näyttönimet, oikeudet ja laskureiden olemassaolo, ja jos ne eivät ole käytettävissä, kirjaa tämä tosiasia ja neuvottele järjestelmänvalvojan kanssa. Katso: Tukiehdot ja asetukset.

1. Kirjaa samassa istunnossa PowerShellissä kellonaika ja istuntotunnus.

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

   Muiden käyttäjien istuntojen kyselemiseen voidaan tarvita lisäoikeuksia. Kohdeprosessin vakiomuotoinen instanssinimi on SessionID:ProcessID <Process Image>. Älä sekoita pelkän istuntotunnuksen perusteella mukaan muiden käyttäjien tai samannimisten prosessien arvoja. Katso: query sessionin oikeudet, Instanssin tunnistaminen.

2. Lisää perfmon.exe:ssä käytettävissä oleva User Input Delay per Process tai User Input Delay per Session.

   Valitse kohdeprosessi tai -istunto ja tarkkaile aluksi oletusarvoisella sekunnin välillä. Erota useita istuntoja yhdistävä koosteinstanssi ja yksittäisen istunnon arvot.

3. Toista toiminto, jossa syöte on hidas, ja vertaa jonossa odottamista oireen ajankohtaan.

   Yksittäisestä mittauskohteesta näet mittausvälin suurimman odotusajan. Vaikka arvo olisi matala, viiveet sovelluksen käsittelyssä syötteen jonosta ottamisen jälkeen ja tuloksen paluussa paikalliselle koneelle jäävät edelleen.

Näin voit tutkia, odotetaanko etäkoneen syötejonossa. Se on eri mittari kuin koettu aika, joka sisältää tietoliikenteen kiertoajan ja näyttämisen paikallisella koneella. Katso: Enimmäisarvon ja mittausvälin merkitys.

flowchart TB
    accTitle: Väli, jonka User Input Delay mittaa
    accDescr: Mittausväli ulottuu etäkoneen syötejonosta siihen, kun sovellus ottaa syötteen jonosta, eikä se sisällä sitä edeltävää ja seuraavaa tietoliikennettä eikä ruudun näyttämistä.
    A["Syöte saapuu paikalliselta koneelta"] --> B["Siirtyy etäkoneen syötejonoon"]
    B -->|"tämä mitataan"| C["Sovellus ottaa syötteen jonosta"]
    C --> D["Sovelluksen käsittely ja ruudun siirto"]
    D --> E["Näytetään paikallisella koneella"]

Kuva 14: Mitataan odotusta etäkoneen syötejonossa. Se eroaa kokonaisajasta, joka kuluu tuloksen näkymiseen paikallisella koneella.

Ruudunpäivitysten ja kehysten ohitusten syiden selvittäminen

Valmistele toiminto, jossa ruutu päivittyy jatkuvasti, kuten vieritys. RemoteFX Graphics -laskureiden saatavuus ja mittauskohta on tarkistettava käyttöjärjestelmän, isännän kokoonpanon ja oikeuksien mukaan. Tässä luetaan vain käytettävissä olevia laskureita. Kyse ei ole ohjeesta vanhan RemoteFX-toiminnon asentamiseen tai käyttöön ottamiseen. Katso: Graphics-laskureiden soveltamisehdot.

1. Tarkista kohdeistunnon nimi komennolla query session tai qwinsta ja valitse vastaava laskuri-instanssi.

2. Vertaa ruutua päivittävän toiminnon aikana arvoja Input Frames/Second ja Output Frames/Second.

   Jos tulostekehyksiä on vähemmän kuin syötekehyksiä, ruudusta ohitetaan kehyksiä matkalla. Tarkista arvot Frames Skipped/Second, jotka on eritelty etäkoneen, verkon ja asiakasohjelman resurssipulan mukaan.

3. Vertaa ohitusten syytä molempien päiden ja tietoliikenteen kuormitukseen ja tarkista myös Average Encoding Time.

   Jos koodausaika on pitkä, selvitä etäkoneen pakkauskäsittely. Jos kehyksiä on vähän jo syötepuolella, voi myös olla, ettei sovellus päivitä ruutua usein. Matala kehysmäärä staattisessa näkymässä ei sinänsä ole poikkeama.

Ruudunpäivityksen aikaisten syöte- ja tulostekehysten, ohitusten syiden ja koodausajan perusteella voit rajata selvityskohdetta. Laskureiden luokittelu on vihje, ja arvio tehdään yhdessä todellisen kuormituksen ja yhteyskokoonpanon kanssa. Katso: Kehysmäärien ja koodausajan tulkinta.

flowchart TB
    accTitle: Selvityskohteen rajaaminen kehysten ohitusten perusteella
    accDescr: Ruutua päivittävän toiminnon aikana verrataan syöte- ja tulostekehysten määrää ja käytetään ohitusten syitä kuvaavia laskureita vihjeenä, kun niitä verrataan käsittelyn, tietoliikenteen ja näyttämisen kuormitukseen.
    A["Vertaa syötettä ja tulostetta vierityksessä"] --> B["Jos tulostetta vähemmän, tarkista ohitukset"]
    B --> C["Katso syykohtaisia laskureita"]
    C --> D["Vertaa etäkoneen, yhteyden ja paikallisen kuormaan"]

Kuva 15: Vertaa vierityksen aikana syötettä ja tulostetta ja vertaa ohitusten syytä etäkoneen, yhteyden ja paikallisen koneen kuormitukseen.

Älä yleistä ruudun siirron käsitekaaviota tai vanhoja aineistoja kaikkiin kokoonpanoihin. Joissakin kokoonpanoissa video ja ääni siirretään erillisellä mekanismilla. Koska Graphics-laskureiden aineisto kuvaa myös vanhoja kokoonpanoja, älä tulkitse siinä mainittuja lukuja yhteiseksi määritykseksi, jonka mukaan ”kaiken RDP:n enimmäisnopeus on 30 fps”. Tarkista ennen käyttöä, mihin toiminnot ja luvut pätevät. Katso: Ruudun siirto ja työkuorma, Graphics-laskureiden aineisto.

Mittaustulosten pätevyysalue

Matalaa lukua ei rinnasteta siihen, että käyttö on sujuvaa. Kunkin mittarin kattavuuden voit tarkistaa ohjeissa mainituista Microsoftin aineistoista.

Tietoliikenteen ja GPU:n asetukset

UDP- ja GPU-asetukset valitaan sen mukaan, mitä vertailut ja mittaukset osoittivat. Jos tietoliikenne on epäilyksenalainen, tarkista ensin yhteystapa ja reitti; jos ruudun käsittely on epäilyksenalainen, tarkista ensin, missä vaiheessa GPU:ta käytetään.

TCP:n, UDP:n ja yhteysreitin tarkistaminen

Jos vertailut ja mittaukset viittaavat tietoliikenteeseen, tarkista järjestelmänvalvojan kanssa käytössä oleva asiakasohjelma, reitti ja sovellettavat käytännöt. Jos asetuksia on muutettava, tee se vain hyväksytyissä rajoissa ja kirjaa arvot ennen muutosta sekä palautustapa. Älä poista palomuuria tai todennusta käytöstä äläkä avaa RDP-porttia suoraan internetiin.

1. Tarkista yhteystietojen, tuotteen diagnostiikkalokien ja järjestelmänvalvojan liikennelokien avulla todellinen TCP/UDP-käyttö ja reitti.

   RDP käyttää kokoonpanon ja tietoliikenneolosuhteiden mukaan TCP:tä tai UDP:tä. Käytäntöasetuksessa ”Select RDP transport protocols” voi valita asetuksen, joka käyttää UDP:tä tai TCP:tä, tai asetuksen, joka käyttää vain TCP:tä. Koska TCP:tä voidaan käyttää, jos UDP-yhteys ei onnistu, pelkkä yhteyden onnistuminen ei kerro, mitä protokollaa käytetään. Katso: RDP-siirtoprotokollan valinta ja paluu TCP:hen.

2. Vertaa reittiä ja protokollaa oireen ajankohtaan ja vertaa vain tarvittavia asetuksia yksi kerrallaan.

   Älä muuta asetuksia yleisen oletuksen ”UDP:n poistaminen nopeuttaa” perusteella. Vertaa pitäen VPN:n ja yhdyskäytävän olosuhteet, toiminnon ja näyttöehdot samoina, ja peru tarpeettomat muutokset.

Kun protokolla ja reitti tunnetaan, voit kirjata muutoksen ja oireen yhteyden. Pelkkään TCP:hen siirtyminen ei aina nopeuta yhteyttä.

flowchart TB
    accTitle: Tarkista yhteystapa ennen tietoliikenneasetusten vertailua
    accDescr: Tavallinen suora yhteys ja yhdyskäytävän tai palvelun kautta kulkeva yhteys erotetaan, todellinen reitti ja protokolla tarkistetaan ja vasta sitten tehdään sallittu vertailu.
    A["Käytössä oleva asiakas ja kokoonpano"] --> B["Tarkista todellinen reitti, TCP tai UDP"]
    B --> C["Vertaa oireen ajankohtaan"]
    C --> D["Vertaa vain tarvittavat asetukset yksitellen"]

Kuva 16: Tarkista käytössä oleva yhteystapa ja reitti, vertaa niitä oireeseen ja vertaa vasta sitten vain tarvittavia asetuksia.

RDP Shortpath on Azure Virtual Desktopin mekanismi. Se muodostaa palvelun UDP-reitin ja käyttää kokoonpanon mukaan suoraa reittiä tai välitystä. Jos reittiä ei saada muodostettua, palataan TCP-pohjaiseen yhteyteen. Sitä ei voi käsitellä samassa asetustaulukossa kuin suoraa mstsc-yhteyttä yrityksen tietokoneeseen. Katso: RDP Shortpathin reitit ja paluu TCP:hen.

flowchart TB
    accTitle: RDP Shortpathin reitit ja paluu TCP:hen
    accDescr: Azure Virtual Desktopin RDP Shortpath yrittää muodostaa UDP-reitin; jos se onnistuu, käytetään kokoonpanon mukaan suoraa reittiä tai välitystä, ja jos ei, palataan TCP-pohjaiseen yhteyteen.
    A["RDP Shortpath"] --> B{"UDP-reitti"}
    B -->|"muodostettu"| C["Suora tai välitetty"]
    B -->|"ei onnistu"| D["Paluu TCP-pohjaiseen"]

Kuva 17: Jos RDP Shortpath ei saa UDP-reittiä muodostettua, palataan TCP-pohjaiseen yhteyteen.

GPU:n käytön tarkistaminen ruudun käsittelyssä

Tee tämä tarkistus, kun vertailut ja mittaukset viittaavat ruudun käsittelyyn. Tarkista ruudun käsittelyn mittaustulokset sekä tuettu käyttöjärjestelmä, ohjain, käytännöt ja asiakasohjelma. Älä muuta asetuksia pelkästään siksi, että koneessa on GPU. Hanki ensin järjestelmänvalvojan hyväksyntä ja valmistele palautusmahdollisuus.

1. Erota etäkoneen sovelluksen renderöinti, RDP:n koodaus ja paikallinen dekoodaus ja valitse epäilyttävä vaihe.

   Vaikka GPU olisi olemassa, kaikki vaiheet eivät välttämättä käytä sitä. Myös Microsoftin Azure Virtual Desktopin kokoonpanoaineistoissa etäistunnon renderöinti ja kehysten laitteistokoodaus määritetään ja tarkistetaan erikseen. Katso: GPU:n määrittäminen ja tarkistaminen renderöintiä ja koodausta varten.

2. Tarkista todellinen käyttö kyseisen tuotteen ohjeiden mukaan ja mittaa sama toiminto ennen tarvittavaa muutosta ja sen jälkeen.

   Jos pakkausaika on pitkä, selvitä GPU:n käyttö koodauksessa. Jos sovellus odottaa syötejonossa, koodausasetusten muuttaminen kohdistuu väärään paikkaan. Tekstin luettavuuden ja videon sujuvuuden kannalta myös kuvanlaadun, tiedonsiirron määrän ja käsittelykuormituksen valinnat eroavat. Katso: Erot työkuorman mukaan.

Näin voit kirjata GPU:n olemassaolon lisäksi, käytettiinkö GPU:ta ongelmallisessa vaiheessa ja miten saman toiminnon kuormitus ja vaste muuttuivat. Peru muutokset, jotka eivät paranna tilannetta, kun olet varmistanut asian järjestelmänvalvojan kanssa.

flowchart TB
    accTitle: GPU:n käytön tarkistaminen vaiheittain
    accDescr: Etäkoneen sovelluksen renderöinti, RDP:n koodaus ja paikallinen dekoodaus erotetaan, ja koska kaikki vaiheet eivät välttämättä käytä GPU:ta, vaikka se olisi olemassa, käyttö tarkistetaan epäilyttävässä vaiheessa.
    A["Etäkoneen sovelluksen renderöinti"] --> B["RDP:n koodaus"]
    B --> C["Paikallinen dekoodaus"]
    C -.- D["Tarkista GPU:n käyttö vaiheittain"]

Kuva 18: Vaikka GPU olisi olemassa, renderöinti, koodaus ja dekoodaus eivät välttämättä kaikki käytä GPU:ta.

Uudelleentarkistus ja luovutus

Parannus varmistetaan sillä, että sama toiminto onnistuu muutoksen jälkeen ongelmitta ja että lisäksi tarvittava kuvanlaatu, laitteet ja työn kannalta tarpeelliset toiminnot säilyvät. Vertaa myös tulosta alkuperäisten ehtojen palauttamisen jälkeen. Jos palautuminen oli vain hetkellistä, älä varmista syytä, vaan kirjaa myös ruuhka-ajat ja samanaikaiset käsittelyt.

flowchart TB
    accTitle: Parannuksen varmistamisen järjestys
    accDescr: Kaavio näyttää, että sen lisäksi, onnistuuko sama toiminto muutoksen jälkeen ongelmitta, tarkistetaan tarvittavan kuvanlaadun, laitteiden ja työtoimintojen säilyminen ja tulosta verrataan alkuperäisten ehtojen palauttamisen jälkeiseen tulokseen, eikä hetkellisen palautumisen perusteella syytä varmisteta.
    A["Kokeile samaa toimintoa muutoksen jälkeen"] --> B["Tarkista kuvanlaatu, laitteet ja toiminnot"]
    B --> C["Vertaa palautuksen jälkeiseen tulokseen"]
    C -.- D["Hetkellinen palautuminen ei varmista syytä"]

Kuva 19: Vertaa saman toiminnon tuloksen lisäksi myös tarvittavia toimintoja ja palautuksen jälkeistä tulosta.

Luovutus, kun ongelma jää ratkaisematta

Myös se, ettei tilanne parane, ongelma ei toistu tai laskurit eivät ole käytettävissä, on hyödyllinen tulos. Erota tehdyt vertailut ja tarkistukset, joita ei voitu tehdä, ja luovuta selvitys järjestelmänvalvojalle tai kehittäjälle seuraavan muistiinpanon avulla. Poista jaettavista lokeista selvityksen kannalta tarpeettomat liiketoimintatiedot, kuten käyttäjänimet ja etäkoneet.

Oireen ilmenemisaika ja aikavyöhyke:
Etäkoneen käyttöjärjestelmä, käytetty asiakasohjelma ja versio:
Suora yhteys / VPN / RD Gateway / Azure Virtual Desktop tms.:
Hidas toiminto ja sovellus, muiden sovellusten vaste samassa istunnossa:
Etäpään näyttötarkkuus ja näyttöjen määrä:
Samanaikainen kopiointi, tulostus tms.:
Ainoa muutettu ehto ja tulos palautuksen jälkeen:
Etäkoneella ja paikallisella koneella havaittu kuormitus tai laskurit:

Lisää myös, voitiinko todellinen TCP/UDP-käyttö tarkistaa, mitkä kohdat jäivät tarkistamatta esimerkiksi puutteellisten oikeuksien vuoksi ja mitkä asetukset ovat työn kannalta hyväksyttäviä. Kun kerrot ”Muistioon voi kirjoittaa normaalisti, mutta kuvien vierittäminen pysähtyy” sen sijaan, että kertoisit ”yhteys on hidas”, seuraava vastuuhenkilö voi selvittää asiaa samoissa olosuhteissa.

Käyttäjä kirjaa toiminnon, jolla ongelma toistuu, ja vertailujen tulokset, ja järjestelmänvalvoja vertaa yhteysreitin, jaetun isännän ja istuntojen lokeja. Pelkkä se, että odotus tapahtuu RDP:n kautta, ei tarkoita, että odotusta aiheuttava käsittely olisi myös RDP. Katso: Isännän ja taustajärjestelmien työnjako.

Sovelluksen kehittäjä kirjaa erikseen syötetapahtuman vastaanoton, tietokanta- ja tiedostokäsittelyn alun ja lopun sekä päivittymisen käyttöliittymään. Harkitaan myös rakennetta, jossa raskas työ ei jää UI-säikeelle. Etäkoneen käsittelyn valmistumisloki ei kuitenkaan kirjaa näyttämisen valmistumista paikallisella koneella. Katso: Käsittelyn erottaminen käyttöliittymän reagointikyvyn säilyttämiseksi.

Aiheeseen liittyviä artikkeleita

• Miten Windowsin istuntojen eristäminen kannattaa ymmärtää
• Windowsin 100 %:n levynkäytön turvallinen vianrajaus
• Miksi ”1 sekunti jäljellä” ei lopu?

Lähteet

Alla ovat Microsoft Learnin ensisijaiset lähteet. Viitattu sisältö tarkistettiin 17. syyskuuta 2026. Erota lukiessasi kunkin tuotteen soveltamisehdot ja huomaa, etteivät ne ole tätä artikkelia varten tehtyjä mittauksia.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. RTT:n erottaminen viiveestä, joka ulottuu ruudun kaappauksesta etäkoneella näyttämiseen paikallisella koneella. Itse diagnostiikkatoiminto on tarkoitettu Azure Virtual Desktopille.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. Ruudun sisällön, näyttötarkkuuden, kehysten päivityksen, pakkauksen ja välimuistin suhde tiedonsiirron määrään.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. Ruudun syöte- ja tulostekehysten, ohitusten syiden ja koodausajan tarkistaminen. Koska aineisto sisältää vanhojen kokoonpanojen kuvauksia, numeerisia ylärajoja ei yleistetä kaikkeen RDP:hen.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. Jaetun isännän kuormitus, liikenne etäkoneelta taustajärjestelmiin ja laitteiden uudelleenohjauksen vaikutus.
• Microsoft Learn, Threading model. WPF:n UI-säie ja Dispatcher sekä käsittelyn erottaminen reagointikyvyn säilyttämiseksi.
• Microsoft Learn, mstsc. Etätyöpöydän leveyden ja korkeuden sekä useiden näyttöjen määrittäminen.
• Microsoft Learn, Supported RDP properties. Työpöydän näyttötarkkuuden, dynaamisen näyttötarkkuuden ja smart sizingin erottaminen. Tarkista tuetut asiakasohjelmat ja kunkin tuotteen soveltamisehdot.
• Microsoft Learn, ping. Vastauksen tarkistaminen ICMP Echon avulla ja valinnat.
• Microsoft Learn, Test-NetConnection. TCP-yhteyden tarkistaminen ja tulosteen merkitys.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. User Input Delayn mittausväli, tuetut käyttöjärjestelmät, instanssit ja enimmäisarvon merkitys.
• Microsoft Learn, query session. Istuntotiedot ja muiden istuntojen kyselemiseen tarvittavat oikeudet.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. RDP:n käyttämän TCP:n ja UDP:n valinta sekä paluu TCP:hen.
• Microsoft Learn, RDP Shortpath. Azure Virtual Desktopin UDP-reitti ja toiminta, jos sitä ei saada muodostettua.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. GPU:n määrittäminen ja tarkistaminen erikseen renderöintiä ja kehysten koodausta varten.

Aiheeseen liittyvät artikkelit

Uusimmat artikkelit, joilla on samoja tunnisteita. Niiden avulla aihetta voi syventää läheisten teemojen kautta.

Aiheeseen liittyvät aihesivut

Tähän teemaan läheisesti liittyviä aihesivuja. Artikkelista voi siirtyä aiheeseen liittyviin palveluihin ja muihin artikkeleihin.

Palvelut, joihin tämä aihe liittyy

Tämä artikkeli liittyy seuraaviin palvelusivuihin. Voitte tutustua lähimpään niistä.

Usein kysytyt kysymykset

Tämän artikkelin aiheesta konsultoinnin yhteydessä usein esitettyjä kysymyksiä.

Nopeustesti näyttää satoja Mbps, miksi kirjoittaminen RDP:ssä on silti hidasta?

Suurten datamäärien siirtonopeus ja aika, joka kuluu ennen kuin toimintoon tulee vastaus, ovat eri asioita. Vaikuttavia tekijöitä ovat syötteen lähetys, etäkoneen sovelluksen käsittely, ruudun pakkaus, siirto ja näyttäminen paikallisella koneella. Lisäksi tietoliikennereitti nopeustestin palvelimelle on eri kuin reitti RDP-etäkoneelle.

Tekstiä voi kirjoittaa normaalisti, mutta vain vieritys nykii. Onko vika yhteydessä?

Syytä ei voi rajata pelkkään yhteyteen. Kun ruudunpäivityksiä tulee enemmän, jokin seuraavista voi jäädä jälkeen: etäkoneen renderöinti ja pakkaus, tietoliikenne tai paikallinen dekoodaus ja näyttäminen. Muuta etäpään näyttötarkkuutta tai näyttöjen määrää yksi kerrallaan ja vertaa, ja tutki tarvittaessa renderöintiin liittyviä laskureita.

Jos ping on nopea, onko RDP:n tietoliikenne kunnossa?

Sen perusteella ei voi päätellä. Ping mittaa vastausta ICMP:hen, ei RDP:n ruudun siirtoa eikä sovelluksen käsittelyä. RD Gatewayn kaltaisia ratkaisuja käyttävissä kokoonpanoissa reittikään ei välttämättä ole sama. Jos vastausta ei tule, erota ICMP:n estäminen siitä, ettei RDP itse saa yhteyttä.

Onko User Input Delay aika näppäimen painamisesta merkin ilmestymiseen?

Ei ole. Se on laskuri, joka mittaa odotusaikaa siitä, kun syöte siirtyy etäkoneella jonoon, siihen, kun prosessi ottaa sen jonosta. Se ei ole koettu viive, joka sisältäisi tietoliikenteen kiertoajan, sovelluksen käsittelyn syötteen jonosta ottamisen jälkeen sekä ruudun pakkauksen, dekoodauksen ja näyttämisen.

Pitäisikö UDP poistaa käytöstä, kun RDP on hidas?

Emme suosittele sitä yleisesti. Tarkista ensin todellinen yhteystapa, reitti ja sovellettavat käytännöt. UDP ei välttämättä ole käytettävissä, jolloin yhteys on voinut palata TCP:hen, eikä pelkkään TCP:hen siirtyminen aina nopeuta yhteyttä. Vertaa järjestelmänvalvojan luvalla samoissa olosuhteissa ja peru tarpeettomat muutokset.

Kirjoittajan profiili

Artikkelin kirjoittajan profiilisivu.

Go Komura

KomuraSoft LLC:n edustaja

Keskittyy Windows-ohjelmistokehitykseen, tekniseen konsultointiin ja vianetsintään. Erityisosaamista ovat hankkeet, joissa on olemassa olevia ratkaisuja, sekä vikojen tutkiminen silloin, kun syy ei ole helposti havaittavissa.