Чаму RDP працуе павольна, хоць канал хуткі? — Асобна правяраем увод, адмалёўку і сетку

Тэст хуткасці паказвае сотні Мбіт/с, а ў аддаленым працоўным стале сімвалы з’яўляюцца з невялікай затрымкай. Пры пракрутцы старонкі з мноствам фотаздымкаў экран тармозіць. Толькі пры націсканні пошуку ў працоўнай праграме ўсё замірае на некалькі секунд. З чаго пачынаць расследаванне такога стану, калі «канал хуткі, а RDP тармозіць»?

Водгук на дзеянні ў RDP не вызначаецца адной толькі хуткасцю перадачы канала. Нават калі тэст хуткасці паказвае высокі вынік, чаканне можа ўзнікаць у адным з месцаў: перадача туды і назад, чаканне ўводу праграмай на аддаленым камп’ютары, кадзіраванне экрана, дэкадзіраванне і адлюстраванне на вашым баку. Спачатку вызначце, «якое менавіта дзеянне павольнае», і параўноўвайце адно і тое ж дзеянне, мяняючы ўмовы па адной. Параўнанні і вымярэнні звужаюць кола пошуку, а налады UDP і GPU выбіраюцца паводле іх вынікаў. Гл.: вымяраныя ўчасткі якасці падключэння, фактары прадукцыйнасці хоста сеансаў.

Аднак на этапе, калі кола пошуку звужана, асноўная прычына яшчэ не ўсталявана. Нават калі пасля зніжэння раздзяляльнасці стала лепш, змяняецца не толькі сеткавая перадача, але і апрацоўка экрана на абодвух баках, таму мы не сцвярджаем, што «прычына была ў канале». Вымераныя і невымераныя ўчасткі мы запісваем у выніках асобна.

У гэтым артыкуле разбіраюцца ўвод, пракрутка і водгук праграм пасля падключэння. Нават пры падобных сімптомах прычына не абавязкова адна. Калі «доўга не з’яўляецца экран уваходу» або «усё спыняецца толькі на аўтэнтыфікацыі», гэта асобная праблема, якую даследуюць па запісах устанаўлення падключэння і аўтэнтыфікацыі.

Артыкул разлічаны перш за ўсё на карыстальнікаў і адміністратараў, якія падключаюцца да Windows 11 або Windows Server з дапамогай праграмы Windows «Remote Desktop Connection» (mstsc). Прыклады каманд прызначаны для Windows PowerShell 5.1. Мяркуецца, што адно і тое ж дзеянне можна ўзнавіць ва ўжо падключаным сеансе.

Пры прамым падключэнні, VPN, RD Gateway і Azure Virtual Desktop адрозніваюцца маршрут, даступная дыягнастычная інфармацыя і тое, да чаго прымяняюцца налады. Прыклад праверкі TCP 3389 датычыць толькі дазволенага прамога падключэння да RDP-хоста, які выкарыстоўвае стандартны порт. Дыягнастычныя функцыі і налады GPU з матэрыялаў для Azure Virtual Desktop мы не пераносім як ёсць на звычайныя офісныя ПК.

На службовых прыладах расследаванне вядзецца ў межах, дазволеных адміністратарам. На агульным хосце вызначце свой сеанс і патрэбны працэс, а калі патрэбныя запісы іншых карыстальнікаў, звярніцеся да адміністратара. Даступнасць лічыльнікаў прадукцыйнасці, іх адлюстраваныя назвы і неабходныя правы правяраюцца ў кожным асяроддзі асобна.

Апісаныя тут спосабы праверкі абапіраюцца на афіцыйныя матэрыялы. Гэта не справаздача пра вымярэнні, у якой непаладка была ўзноўлена і ўхілена на канкрэтнай прыладзе. Лікавыя прыклады пазначаны асобна як дапушчэнні для тлумачэння.

Механізм можна чытаць па парадку, пачынаючы з наступнага раздзела «Хуткасць перадачы і час туды і назад». Калі хочаце пачаць з сімптому, пераходзьце да раздзела «Першае параўнанне паводле сімптому». Парадак дзеянняў апісаны ў раздзелах «Параўнанне ўмоў па адной» і «Вымярэнне месца чакання».

На схеме суцэльная лінія пазначае сувязь, якая выконваецца заўсёды, а пункцірная — умоўную сувязь (умовы пададзены ў апісанні кожнай сувязі на старонцы з падрабязнасцямі). Поўны спіс сувязей (усяго 7, з падставамі і ступенню пэўнасці) і азначэнні асноўных паняццяў сабраны на старонцы з падрабязнасцямі карты ведаў (па-японску). Даныя: JSON-LD / Turtle

Хуткасць перадачы і час туды і назад

RDP (Remote Desktop Protocol) — гэта пратакол, з дапамогай якога лакальная прылада і аддалены камп’ютар абменьваюцца ўводам, звесткамі пра экран і іншымі данымі. Ён перадае не толькі экран і ўвод, але і даныя перанакіравання прылад, друку і г. д. Гл.: што перадае RDP.

Хуткасць перадачы канала паказвае, колькі даных можна перадаць за секунду. «500 Мбіт/с» у тэсце хуткасці — лічба менавіта пра гэты аб’ём. Яна не паказвае, колькі часу праходзіць ад дзеяння да атрымання адказу. Гл.: патрабаванні RDP да прапускной здольнасці.

flowchart TB
    accTitle: Што паказвае лічба тэсту хуткасці
    accDescr: Паказана, што 500 Мбіт/с у тэсце хуткасці — гэта аб'ём даных, які можна перадаць за секунду, а не час ад дзеяння да атрымання адказу.
    A["Тэст хуткасці: 500 Мбіт/с"] --> B["Аб'ём даных за секунду"]
    B -.->|"Іншая лічба"| C["Час да атрымання адказу"]

Малюнак 1: Лічба тэсту хуткасці паказвае аб’ём перадачы, а не час, за які прыходзіць адказ.

Час туды і назад (RTT) — гэта час, за які даныя дасягаюць іншага боку і вяртаюцца. Розніца паміж павелічэннем хуткасці перадачы і скарачэннем часу туды і назад падобная да розніцы паміж даданнем палос на дарозе і скарачэннем адлегласці да месца прызначэння. Нават калі здольнасць перавозіць вялікія файлы расце, пры нязменным часе туды і назад чаканне адказу на дзеянне застаецца. Гл.: RTT і затрымка адлюстравання экрана.

flowchart TB
    accTitle: Хуткасць перадачы і час туды і назад на прыкладзе дарогі
    accDescr: Павелічэнне хуткасці перадачы параўноўваецца з даданнем палос на дарозе, а скарачэнне часу туды і назад — са скарачэннем адлегласці да месца прызначэння.
    A["Павялічыць хуткасць перадачы"] -->|"На дарозе"| B["Дадаць палосы"]
    B ~~~ C["Скараціць час туды і назад"]
    C -->|"На дарозе"| D["Скараціць адлегласць"]

Малюнак 2: Дадатковыя палосы не скарачаюць адлегласць да месца прызначэння.

Вяртанне выніку для аднаго сімвала

Уявім, што вы ўводзіце адзін сімвал у Notepad на аддаленым камп’ютары. Notepad працуе на аддаленым камп’ютары. Калі для тлумачэння дапусціць, што дзеянне даходзіць за 50 мілісекунд, а звесткі пра экран з вынікам вяртаюцца яшчэ за 50 мілісекунд, то на сеткавую перадачу сыходзіць разам 100 мілісекунд, гэта значыць 0,1 секунды. Час апрацоўкі на абодвух баках у гэты прыклад не ўключаны.

flowchart TB
    accTitle: Прыклад сеткавага часу да вяртання выніку для аднаго сімвала
    accDescr: Для тлумачэння дапушчана, што шлях туды і шлях назад займаюць па 50 мілісекунд. Час апрацоўкі на абодвух баках не ўключаны, і гэта не колькасць пакетаў на кожную клавішу.
    A["Увод аднаго сімвала лакальна"] -->|"Туды: 50 мс"| B["Аддалены ПК атрымлівае ўвод"]
    B --> C["Адпраўка экрана з уводам"]
    C -->|"Назад: 50 мс"| D["Вынік прыходзіць лакальна"]

Малюнак 3: Калі дапусціць 50 мілісекунд туды і 50 мілісекунд назад, толькі на сеткавую перадачу сыходзіць 0,1 секунды. Гэта не вымераныя значэнні.

Нават калі прапускная здольнасць канала расце, гэтыя 0,1 секунды застаюцца, пакуль не зменіцца час туды і назад. Малюнак 3 — канцэптуальная схема для разумення апрацоўкі. Ён не азначае, што на кожную клавішу адпраўляецца асобны пакет туды і назад. Маршрут да сервера тэсту хуткасці і да аддаленага камп’ютара RDP таксама розны, таму трэба ўлічваць VPN, шлюзы, выходны канал на баку аддаленага камп’ютара і перагрузку па дарозе. Гл.: падыход да RTT, прадукцыйнасць сеткі і хоста.

Стварэнне і дастаўка выявы экрана

Затрымка водгуку на дзеянні тут — гэта чаканне ад дзеяння на вашым баку да моманту, калі вы бачыце вынік. Яна залежыць не толькі ад RTT, але і ад апрацоўкі ў праграме і ад стварэння і дастаўкі выявы экрана. Мы таксама адрозніваем яе ад затрымкі толькі на ўчастку перадачы экрана. Гл.: вымяраныя ўчасткі ад захопу экрана да адлюстравання.

Калі ўвод даходзіць з вашай прылады да аддаленага камп’ютара, праграма на аддаленым камп’ютары апрацоўвае ўвод і абнаўляе экран, закадзіраваныя звесткі пра экран перадаюцца па канале, а на вашым баку яны дэкадзіруюцца і адлюстроўваюцца. І да, і пасля сеткавай перадачы ёсць праца, якую выконваюць розныя ПК. Гл.: апрацоўка ад захопу экрана да адлюстравання.

flowchart TB
    accTitle: Апрацоўка экрана ёсць і да, і пасля канала
    accDescr: Ход ад лакальнага ўводу, які даходзіць да аддаленага камп'ютара, праз апрацоўку ў праграме, стварэнне і сцісканне экрана і перадачу звестак пра экран па канале да вяртання іх у форму для паказу і адлюстравання на вашым баку.
    I["Лакальна: увод дзеяння"] --> J["Канал: перадача ўводу"]
    J --> K["Аддалены ПК: апрацоўка ў праграме"]
    K --> A["Аддалены ПК: стварэнне і сцісканне экрана"]
    A --> B["Канал: перадача звестак пра экран"]
    B --> C["Лакальна: вяртанне ў форму для паказу"]
    C --> D["Паказ на лакальным экране"]

Малюнак 4: Апрацоўка і сцісканне на аддаленым камп’ютары, перадача па канале і вяртанне да паказу на вашым баку — праца, якая выконваецца ў розных месцах.

Кадзіраванне ў гэтым артыкуле — гэта ператварэнне і сцісканне выявы экрана на аддаленым камп’ютары ў форму, зручную для адпраўкі. Яно займае час апрацоўкі на аддаленым камп’ютары асобна ад перадачы па канале. Гл.: час кадзіравання на аддаленым камп’ютары.

Дэкадзіраванне ў гэтым артыкуле — гэта вяртанне атрыманых звестак пра экран у форму, якую можна паказаць на вашым баку. Мы адрозніваем яго ад расшыфроўкі ў сэнсе здымання шыфравання. Гл.: час дэкадзіравання і адлюстравання на вашым баку.

Калі сцісканне на аддаленым камп’ютары займае шмат часу, давядзецца чакаць падрыхтоўкі да адпраўкі, нават калі канал вольны. Нават калі звесткі ўжо дайшлі, абнаўленне спазняецца, калі дэкадзіраванне або адлюстраванне на вашым баку не паспявае. Думка «службовы ПК магутны, значыць, лакальная прылада можа быць любой» не заўсёды правільная. Запас канала і запас апрацоўкі на яго абодвух канцах — розныя рэчы. Гл.: лічыльнікі прадукцыйнасці апрацоўкі экрана.

flowchart TB
    accTitle: Затрымка, калі апрацоўка на абодвух баках не паспявае
    accDescr: Паказана, што калі сцісканне на аддаленым камп'ютары доўгае, адпраўка чакае падрыхтоўкі нават пры вольным канале, а калі дэкадзіраванне або адлюстраванне на вашым баку не паспявае, абнаўленне спазняецца, нават калі звесткі дайшлі.
    A["Сцісканне на аддаленым ПК доўгае"] --> B["Адпраўка чакае пры вольным канале"]
    B ~~~ C["Лакальнае дэкадзіраванне не паспявае"]
    C --> D["Даныя дайшлі, абнаўленне спазняецца"]

Малюнак 5: Нават калі ў канале ёсць запас, абнаўленне экрана спазняецца, калі апрацоўка на абодвух баках не паспявае.

Розніца паміж уводам тэксту і пракруткай

Калі дадаць адзін сімвал у Notepad, змяняецца невялікая частка экрана. Калі пракручваць старонку з мноствам фотаздымкаў, адзін за адным змяняецца паказ на вялікай плошчы. RDP памяншае аб’ём трафіку, перадаючы змененыя ўчасткі і выкарыстоўваючы сцісканне і кэшаванне, якія адпавядаюць змесціву. Ён не адпраўляе кожны раз увесь экран без сціскання. Аб’ём працы залежыць ад змесціва экрана і частаты абнаўленняў. Гл.: сувязь змесціва экрана і прапускной здольнасці.

flowchart TB
    accTitle: Аб'ём працы з экранам пры ўводзе тэксту і пракрутцы
    accDescr: Пры невялікай змене аднаго сімвала і пры бесперапынным абнаўленні вялікай плошчы праца па стварэнні і адпраўцы экрана мае розны характар.
    A{"Змена экрана"} -->|"Дадаць адзін сімвал"| B["Невялікая плошча"]
    A -->|"Пракрутка"| D["Вялікая плошча, бесперапынна"]
    B --> E["Сцісканне і перадача паводле змены"]
    D --> E

Малюнак 6: Нават у адным і тым жа падключэнні аб’ём працы розны, калі дадаецца адзін сімвал і калі бесперапынна рухаецца вялікая плошча.

Нават калі нерухомы дакумент не стварае нагрузкі, падчас пракруткі запас на перадачу экрана можа скончыцца. Калі павялічыць раздзяляльнасць на аддаленым баку або колькасць манітораў, экран для апрацоўкі таксама становіцца большым. Параўнанне са зніжанай раздзяляльнасцю — гэта эксперымент, які паказвае, ці вяртаецца плаўнасць, калі памяншаецца праца па стварэнні і адпраўцы экрана. Гэта не разлік, які вызначае аб’ём трафіку толькі па колькасці пікселяў. Гл.: уплыў раздзяляльнасці, абнаўленняў экрана і сціскання.

Чаканне ў праграме

Калі ў працоўнай праграме на некалькі секунд замірае толькі пошук, а ў Notepad у тым жа сеансе можна нармальна набіраць тэкст, мы правяраем, чаго чакае гэтая праграма. Праграма на аддаленым камп’ютары можа ў сваю чаргу адпраўляць пошукавы запыт да іншай БД або чытаць файл з агульнай папкі і чакаць адказу. Гэта іншы маршрут, чым сувязь RDP паміж вашай прыладай і аддаленым камп’ютарам. Гл.: сувязь ад аддаленага камп’ютара да бэкенда.

flowchart TB
    accTitle: За RDP ёсць і іншыя бакі сувязі
    accDescr: Паказаны выпадак, калі праграма на аддаленым камп'ютары чакае адказу ад працоўнага сервера асобна ад сувязі паміж вашай прыладай і аддаленым камп'ютарам.
    A["Лакальная прылада"] -->|"RDP"| B["Працоўная праграма на аддаленым ПК"]
    B -->|"Пошук і запыт файлаў"| C["БД і агульная папка"]
    C -->|"Чаканы адказ"| B

Малюнак 7: Працоўная праграма за RDP можа ў сваю чаргу чакаць адказу ад іншага сервера.

Калі код, які адказвае за экран і ўвод, заняты доўгай працай, наступны ўвод і абнаўленне экрана спазняюцца. Напрыклад, у WPF доўгае займанне UI-патоку пагаршае хуткасць водгуку. Адна толькі нізкая агульная загрузка CPU не выключае чакання ў пэўным UI-патоку. Гл.: Dispatcher і UI-паток.

flowchart TB
    accTitle: Код, адказны за экран і ўвод, затрымліваецца
    accDescr: Паказана, што калі код, які адказвае за экран і ўвод, заняты доўгай працай, наступны ўвод і абнаўленне экрана спазняюцца, а адна толькі нізкая агульная загрузка CPU не выключае гэтага чакання.
    A["Код, адказны за экран і ўвод"] --> B["Заняты доўгай працай"]
    B --> C["Наступны ўвод і абнаўленне спазняюцца"]
    C -.- D["Нізкі агульны CPU гэтага не выключае"]

Малюнак 8: Чаканне ў UI-патоку нельга выключыць толькі па агульнай загрузцы CPU.

Першае параўнанне паводле сімптому

Аб’ём, які можна перадаць, час чакання адказу і час на стварэнне і паказ экрана — розныя рэчы. Калі трымаць гэтае адрозненне ў галаве, можна не зводзіць «RDP тармозіць» да адной прычыны, а пачынаць з таго дзеяння, якое павольнае зараз.

flowchart TB
    accTitle: Спачатку раздзяліць тры рэчы, потым даследаваць
    accDescr: Паказана, што «RDP тармозіць» не зводзіцца да адной прычыны: аб'ём перадачы, час чакання адказу і час на стварэнне і паказ экрана разглядаюцца асобна, а расследаванне пачынаецца з дзеяння, якое павольнае зараз.
    A["«RDP тармозіць»"] --> S
    subgraph S["Разглядаць асобна"]
    direction TB
    B["Аб'ём перадачы"] ~~~ C["Час чакання адказу"]
    C ~~~ D["Час на стварэнне і паказ экрана"]
    end
    S --> E["Пачаць з дзеяння, якое павольнае"]

Малюнак 9: Калі раздзяліць аб’ём перадачы, час чакання адказу і час на стварэнне і паказ экрана, можна пачаць з дзеяння, якое павольнае зараз.

Мэта дыягностыкі — абмежаваць месца, дзе шукаць прычыну павольнасці. Масава змяніць налады і выпадкова паскорыць працу — не мэта. Выкарыстоўваючы такія адрозненні, як «Notepad працуе, а замірае толькі пошук» або «увод тэксту нармальны, а тармозіць толькі пракрутка», можна выбраць адпраўную кропку расследавання яшчэ да змены сеткавых налад.

Табліца ніжэй — адпраўная кропка расследавання. Гэта не табліца для вызначэння прычыны. Дзеянні спачатку параўноўваюцца ў тым жа сеансе, а потым мяняюцца патрэбныя прылада, маршрут і ўмовы адлюстравання.

Сімвалы спазняюцца ў некалькіх праграмах

Калі ў некалькіх праграмах аднаго сеанса кожны сімвал з’яўляецца з затрымкай, мы параўноўваем тое ж дзеянне на іншай прыладзе або праз іншы дазволены маршрут. Мы супастаўляем час туды і назад, чаканне ўводу на аддаленым камп’ютары і яго агульную нагрузку і не вызначаем прычыну па адной лічбе.

Рыўкамі ідзе толькі пракрутка

Нават калі ўвод тэксту нармальны, пры пракрутцы старонкі з мноствам фотаздымкаў бесперапынна абнаўляецца вялікая плошча экрана. Мы мяняем па адной раздзяляльнасць на аддаленым баку або колькасць манітораў і параўноўваем на той жа старонцы. Калі стала лепш, наступныя аб’екты расследавання — сцісканне на аддаленым камп’ютары, перадача экрана і лакальнае дэкадзіраванне. Толькі па раздзяляльнасці нельга сказаць, што з гэтых трох з’яўляецца прычынай. Гл.: нагрузка ў залежнасці ад змесціва экрана і раздзяляльнасці.

Завісае толькі адна праграма

Калі замірае толькі працоўная праграма, у якой націснулі пошук, мы правяраем, ці адказвае Notepad або іншая праграма ў тым жа сеансе. Калі іншая праграма працуе, спачатку даследуюцца апрацоўка ў патрэбнай праграме, дыск і запыты да БД або агульнай папкі. Тое, што вы працуеце праз RDP, і тое, што чаканне выклікана сувяззю RDP, — розныя рэчы. Гл.: фактары прадукцыйнасці праграм і бэкенда.

Ва ўсіх павольна толькі тады, калі карыстальнікаў больш

Калі ў адзін і той жа час запавольванне адчуваюць некалькі карыстальнікаў, мы пытаемся ў адміністратара пра стан іншых сеансаў. Нагрузку на CPU, памяць і сховішча агульнага хоста і на агульны канал мы супастаўляем з часам сімптому. Мы не звяртаемся без дазволу да запісаў і працэсаў іншых карыстальнікаў і не спыняем іх заданні. Гл.: рэсурсы агульнага хоста і колькасць карыстальнікаў.

Запаволенне падчас капіявання або друку

Калі пачатак вашага капіявання або друку супадае з праблемамі, мы часова спыняем толькі тыя перадачы, якія дазволена спыняць, і параўноўваем. Мы запісваем, ці вяртаецца хуткасць пасля прыпынку і ці зноў становіцца павольна пасля аднаўлення, і даследуем канкурэнцыю з перадачамі, не звязанымі з экранам, і з перанакіраваннем прылад. Параўнанняў, пры якіх масава адключаюцца прылады, патрэбныя для працы, мы не робім. Гл.: уплыў перанакіравання прылад.

Параўнанне ўмоў па адной

Мяняць усе налады па чарзе не трэба. Спачатку ствараецца база для параўнання, а потым выбіраюцца толькі тыя праверкі, якія адпавядаюць сімптому. Перад зменай налад або перападключэннем захавайце працу і запішыце зыходныя значэнні і спосаб іх вярнуць. Калі неабходных правоў або функцый няма, мы не ўключаем іх сілай, а перадаём справу адміністратару.

Лакальная праца і праца праз RDP не абавязкова адбываюцца ў аднолькавых умовах. Тое, што на фізічным экране аддаленага камп’ютара ўсё хутка, — карысная падказка, але ўмовы сеанса або адмалёўкі могуць змяняцца. Выраўнуйце карыстальніка, даныя і стан праграмы і не зводзьце прычыну да канала толькі таму, што «на фізічным экране хутка».

Параўнанне аднаго і таго ж дзеяння

Для параўнання бяруцца той жа карыстальнік, тыя ж даныя і тое ж дзеянне. На агульным хосце мы правяраем свой сеанс і не спыняем праграмы і працэсы іншых карыстальнікаў. Выкарыстанне іншай прылады або іншага маршруту таксама абмяжоўваецца межамі, дазволенымі адміністратарам.

1. Узнавіце павольнае дзеянне з зыходнымі наладамі і запішыце час і сімптом.

   У Notepad у тым жа аддаленым сеансе, што і праблемная праграма, увядзіце прыкладна столькі ж тэксту. Адрознівайце, ці праблема толькі ў адной праграме, ці ва ўсім сеансе.

2. Праверце нагрузку на аддаленым камп’ютары і на вашым баку ў адзін і той жа прамежак часу.

   У Task Manager на аддаленым камп’ютары глядзіце CPU, памяць і дыск патрэбнай праграмы, а на вашым баку — нагрузку ад кліента RDP. Правярайце не толькі агульнае значэнне CPU, але і патрэбны працэс. Гл.: што правяраць пры аналізе нагрузкі.

3. Змяніце толькі адну ўмову — іншая прылада, іншы дазволены маршрут або ўмовы адлюстравання — і паўтарыце тое ж дзеянне.

   Калі пры параўнанні адначасова змяняецца і стан аддаленага камп’ютара або праграмы, запішыце і гэтую розніцу. Вынік, у якім змянілася некалькі ўмоў, не лічыце эфектам адной умовы.

4. Вярніце зыходныя ўмовы і зноў праверце тое ж дзеянне.

   Калі і пасля вяртання ўсё застаецца хуткім, магчыма, справа ў часовай змене нагрузкі або нечым падобным. Не лічыце адразу, што змена дапамагла, і запішыце ўмовы, пры якіх сімптом узнаўляецца.

Калі ёсць вынікі для зыходнага стану, пасля змены і пасля вяртання, можна параўнаць, якія ўмовы адпавядаюць якім сімптомам. Умова, пры якой стала лепш, — гэта падказка для расследавання, але сама па сабе яна не даказвае асноўнай прычыны.

flowchart TB
    accTitle: Абмежаваць умовы, якія мяняюцца за раз
    accDescr: Ход, у якім вызначаецца дзеянне, што ўзнаўляецца ў зыходным стане, для параўнання мяняецца толькі адна ўмова і правяраецца таксама вынік пасля вяртання.
    A["Тое ж дзеянне з зыходнымі наладамі"] --> B["Змяніць толькі адну ўмову"]
    B --> C["Паўтарыць тое ж дзеянне"]
    C --> D["Вярнуць і праверыць зноў"]
    D --> E["Запісаць умову, з якой стала лепш"]

Малюнак 10: Тое ж дзеянне паўтараецца ў зыходным стане, пасля змены і пасля вяртання, і запісваецца ўмова, якая дала змену.

Параўнанне раздзяляльнасці на аддаленым баку

Гэта параўнанне праводзіцца, калі цяжка даюцца абнаўленні экрана, напрыклад пры пракрутцы. Мы запісваем раздзяляльнасць і колькасць манітораў да змены, захоўваем працу і перападключаемся. Налады, якія пагаршаюць неабходныя для працы экраны або чытэльнасць тэксту, мы не выкарыстоўваем пастаянна.

1. Змяніце толькі адно: колькасць манітораў або раздзяляльнасць.

   У mstsc параўнаць можна з дапамогай налад укладкі «Display» перад падключэннем або задання шырыні і вышыні. Гл.: заданне экрана ў mstsc.

2. Пераканайцеся, што фактычны памер аддаленага працоўнага стала змяніўся, і пракруціце тую ж старонку.

   Калі толькі зменшыць акно на вашым баку, можа аказацца, што вялікі працоўны стол проста паказваецца ў паменшаным выглядзе. Адрознівайце дынамічную раздзяляльнасць і smart sizing і праверце, што з гэтага падтрымлівае ваш кліент. Гл.: раздзяляльнасць працоўнага стала і маштаб адлюстравання.

3. Вярніце зыходныя налады, паўтарыце тое ж дзеянне і параўнайце нагрузку на абодвух баках і рух выявы на экране.

   Калі вы адначасова знізілі раздзяляльнасць і звялі ўсё да аднаго манітора, параўнанне будзе толькі прыблізным. Калі стала лепш, вяртайце налады па адной, каб раздзяліць іх уплыў.

Калі стала лепш, падказка знаходзіцца ў галіне апрацоўкі і перадачы экрана. 3840×2160 мае ў 4 разы больш пікселяў, чым 1920×1080, але аб’ём трафіку не заўсёды павялічваецца ў 4 разы. Ён залежыць ад змененых участкаў і сціскання, а змена раздзяляльнасці ўплывае і на апрацоўку на абодвух баках. Гл.: колькасць пікселяў і аб’ём трафіку, праверка апрацоўкі экрана.

flowchart TB
    accTitle: Што паказвае параўнанне са зніжанай раздзяляльнасцю
    accDescr: Калі знізіць раздзяляльнасць на аддаленым баку, можа змяніцца нагрузка і на апрацоўку экрана, і на перадачу, таму адно толькі паляпшэнне не дазваляе звесці прычыну да канала.
    A["Знізіць раздзяляльнасць на аддаленым баку"] --> S
    subgraph S["Што мяняецца"]
    direction TB
    B["Апрацоўка экрана на аддаленым ПК"] ~~~ C["Аб'ём звестак для адпраўкі"]
    C ~~~ D["Лакальная апрацоўка паказу"]
    end

Малюнак 11: Змена раздзяляльнасці — гэта параўнанне, якое ўплывае не толькі на канал, але і на апрацоўку экрана на аддаленым камп’ютары і на вашым баку.

Супастаўленне капіявання і друку з сімптомамі

Часова спыняюцца толькі працэсы, якія дазволена спыняць, напрыклад перадачы, што запусцілі вы самі. Рэзервовае капіраванне і працэсы бяспекі кампаніі, а таксама заданні іншых карыстальнікаў мы не спыняем. Перанакіраванне аўдыя і прылад уводу, патрэбных для працы, мы масава не адключаем.

1. Да пачатку і падчас капіявання, сінхранізацыі з воблакам або друку запішыце тое ж дзеянне і нагрузку.

   Па RDP, акрамя экрана, перадаюцца і даныя дыскаў, прынтараў і іншага. Перанакіраванне, якое дазваляе выкарыстоўваць вашы прылады на аддаленым камп’ютары, можа павялічваць нагрузку на сетку і апрацоўку, калі гэтыя прылады выкарыстоўваюцца. Гл.: уплыў перанакіравання прылад.

2. Часова спыніце патрэбную перадачу ў дазволеных межах і зноў праверце тое ж дзеянне.

   Калі можна аднавіць перадачу і параўнаць, запішыце і сімптомы пасля аднаўлення. Калі спрабуеце адключаць непатрэбныя перанакіраванні прылад, таксама мяняйце іх па адным так, каб можна было вярнуць зыходныя налады.

Можна ацаніць, ці адпавядаюць пачатак перадачы праблемам, а прыпынак — аднаўленню. Калі адпаведнасць бачная, перадачы, не звязаныя з экранам, і нагрузку на агульныя рэсурсы супастаўляюць з запісамі адміністратара.

flowchart TB
    accTitle: Стан да і пасля праблемы на адной часавай шкале
    accDescr: Тое ж дзеянне і нагрузка запісваюцца да перадачы, падчас яе і пасля прыпынку, каб параўнаць сувязь праблемы з працай.
    A["Дзеянне і нагрузка да перадачы"] --> B["Дзеянне і нагрузка падчас перадачы"]
    B --> C["Дзеянне і нагрузка пасля прыпынку"]
    C --> D["Ці адпавядаюць праблема і аднаўленне"]

Малюнак 12: Глядзім, як мяняюцца павольнасць аднаго і таго ж дзеяння і нагрузка да перадачы, падчас яе і пасля прыпынку.

Вымярэнне месца чакання

З вашага боку правяраюцца перадача туды і назад і TCP-падключэнне, а на аддаленым камп’ютары — чаканне ў чарзе ўводу і абнаўленне экрана. Кожная лічба ахоплівае толькі абмежаваны ўчастак, таму вынікі чытаюцца разам з табліцай у раздзеле «Межы вынікаў вымярэнняў».

Праверка ICMP і TCP-падключэння

Каманды выконваюцца на вашай лакальнай прыладзе з Windows. Разглядаецца толькі канфігурацыя з прамым падключэннем да RDP-хоста, які выкарыстоўвае стандартны TCP 3389, праз карпаратыўную лакальную сетку або дазволены VPN. Для канфігурацый праз RD Gateway або Azure Virtual Desktop ці з нестандартным портам вызначце, што правяраць, разам з адміністратарам. Мы не адкрываем парты і не змяняем налады брандмаўэра.

1. Увядзіце дазволены аддалены хост і запішыце вынікі адказу ICMP і TCP-падключэння.

   $target = Read-Host 'Імя або IP-адрас RDP-хоста, які дазволена даследаваць'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'Укажыце хост для падключэння.'
   }
       
   # Некалькі разоў глядзім час адказу ICMP. Адна няўдача не азначае, што RDP недаступны.
   ping.exe -n 20 $target
       
   # Праверка толькі для прамога падключэння да стандартнага TCP 3389.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. Супастаўце вынікі ў павольны і ў звычайны час з часам сімптому і фактычным маршрутам падключэння.

   20 запытаў ping — гэта кароткае назіранне. Ваганні значэнняў і адсутнасць адказу запісваюцца, але ICMP можа быць заблакаваны. Перарывістыя спыненні не выключаюцца толькі па сярэднім значэнні: выкарыстоўваюцца звесткі пра падключэнне і сеткавыя запісы адміністратара. Гл.: што вымярае ping.

TcpTestSucceeded: True азначае, што TCP-падключэнне да зададзенага порта ўдалося. Прапускная здольнасць, UDP, дзеянні пасля аўтэнтыфікацыі і плаўнасць экрана не вымяраюцца. У Test-NetConnection няма пераключальніка -UDP для праверкі UDP. Гл.: сінтаксіс і вынікі Test-NetConnection.

Вынікі ацэньваюцца з улікам розніцы ў маршрутах і службах. У RD Gateway і падобных канфігурацыях маршрут ICMP або прамога TCP-падключэння да хоста можа не супадаць з фактычным маршрутам RDP. У Azure Virtual Desktop даступныя RTT і ацэнка прапускной здольнасці для кожнага падключэння, але гэтыя дыягнастычныя функцыі прызначаны для гэтай службы. Кароткія спыненні мы не выключаем толькі па сярэдніх значэннях. Гл.: журналы якасці падключэння Azure Virtual Desktop.

flowchart TB
    accTitle: Правераны маршрут і фактычны маршрут RDP
    accDescr: У канфігурацыях з RD Gateway і падобнымі маршрут ICMP або прамога TCP-падключэння ад вашай прылады да хоста можа не супадаць з фактычным маршрутам RDP.
    A["Лакальная прылада"] -->|"ICMP і прамы TCP"| C["RDP-хост"]
    A -->|"Фактычны RDP"| B["RD Gateway і г. д."]
    B --> C

Малюнак 13: Маршрут ICMP або прамога TCP-падключэння да хоста і маршрут фактычнага RDP могуць не супадаць.

Вымярэнне чакання ў чарзе ўводу

User Input Delay вымярае чаканне ад моманту, калі ўвод трапляе ў чаргу на аддаленым камп’ютары, да моманту, калі працэс яго забірае. Гэта не агульны час ад націскання клавішы да з’яўлення сімвала. Гл.: азначэнне User Input Delay.

Праверка выконваецца ў аддаленым сеансе на аддаленым камп’ютары. Паводле Microsoft, падтрымліваюцца Windows 10 версіі 1809 і навейшыя і Windows Server 2019 і навейшыя. Для гэтых сістэм дадаваць запіс у рэестр для ўключэння не трэба. Мы правяраем адлюстраваныя назвы, правы і наяўнасць лічыльнікаў, а калі яны недаступныя, запісваем гэты факт і раімся з адміністратарам. Гл.: падтрымліваемыя сістэмы і налады.

1. У PowerShell у тым жа сеансе запішыце час і ідэнтыфікатар сеанса.

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

   Для запыту сеансаў іншых карыстальнікаў могуць спатрэбіцца дадатковыя правы. Стандартнае імя экзэмпляра для патрэбнага працэсу — SessionID:ProcessID <Process Image>. Сачыце, каб не змешваць значэнні іншых карыстальнікаў або аднайменных працэсаў, арыентуючыся толькі на ідэнтыфікатар сеанса. Гл.: правы для query session, ідэнтыфікацыя экзэмпляраў.

2. У perfmon.exe дадайце даступны лічыльнік User Input Delay per Process або User Input Delay per Session.

   Выберыце патрэбны працэс або сеанс і спачатку назірайце з інтэрвалам па змаўчанні ў 1 секунду. Адрознівайце агрэгаваны экзэмпляр, які аб’ядноўвае некалькі сеансаў, і значэнні асобных сеансаў.

3. Узнавіце дзеянне з павольным уводам і параўнайце чаканне ў чарзе з часам сімптому.

   Для асобнага аб’екта вымярэння паказваецца максімальны час чакання на працягу інтэрвалу вымярэння. Нават калі значэнне нізкае, затрымкі ў апрацоўцы пасля таго, як праграма забрала ўвод, і да вяртання выніку на ваш бок застаюцца.

Так можна даследаваць, ці ўзнікае чаканне ў чарзе ўводу на аддаленым камп’ютары. Гэта паказчык, адрозны ад адчувальнага часу, які ўключае перадачу туды і назад і адлюстраванне на вашым баку. Гл.: сэнс максімальнага значэння і інтэрвалу вымярэння.

flowchart TB
    accTitle: Участак, які вымярае User Input Delay
    accDescr: Вымяраецца ўчастак ад чаргі ўводу на аддаленым камп'ютары да моманту, калі праграма забірае ўвод; сеткавая перадача і адлюстраванне экрана да і пасля яго не ўключаюцца.
    A["Увод прыходзіць з лакальнай прылады"] --> B["Трапляе ў чаргу ўводу на аддаленым ПК"]
    B -->|"Вымяраецца тут"| C["Праграма забірае ўвод"]
    C --> D["Апрацоўка ў праграме і перадача экрана"]
    D --> E["Паказ на лакальнай прыладзе"]

Малюнак 14: Вымяраецца чаканне ў чарзе ўводу на аддаленым камп’ютары. Гэта не агульны час да таго, як вы ўбачыце вынік.

Даследаванне абнаўлення экрана і прычын пропуску кадраў

Рыхтуецца дзеянне з бесперапынным абнаўленнем экрана, напрыклад пракрутка. Даступнасць лічыльнікаў RemoteFX Graphics і месца вымярэння трэба правяраць у залежнасці ад АС, канфігурацыі хоста і правоў. Тут мы толькі чытаем даступныя лічыльнікі. Гэта не інструкцыя па ўсталяванні або ўключэнні старой функцыі RemoteFX. Гл.: умовы прымянення лічыльнікаў Graphics.

1. З дапамогай query session або qwinsta высветліце імя патрэбнага сеанса і выберыце адпаведны экзэмпляр лічыльніка.

2. Падчас дзеяння з абнаўленнем экрана параўнайце Input Frames/Second і Output Frames/Second.

   Калі выходных кадраў менш, чым уваходных, частка кадраў па дарозе прапускаецца. Праверце значэнні Frames Skipped/Second паводле прычын: недахоп рэсурсаў на аддаленым камп’ютары, у сетцы або ў кліенце.

3. Супастаўце прычыны пропуску кадраў з нагрузкай на абодвух баках і на сетку і праверце таксама Average Encoding Time.

   Калі час кадзіравання доўгі, даследуйце сцісканне на аддаленым камп’ютары. Калі кадраў мала ўжо на ўваходзе, магчыма, праграма проста не абнаўляе экран часта. Нізкая колькасць кадраў на нерухомым экране сама па сабе не з’яўляецца анамаліяй.

Па ўваходных і выходных кадрах падчас абнаўлення экрана, прычынах пропуску і часе кадзіравання можна звузіць кола пошуку. Класіфікацыя лічыльнікаў — толькі падказка, і высновы робяцца з улікам фактычнай нагрузкі і канфігурацыі падключэння. Гл.: як чытаць колькасць кадраў і час кадзіравання.

flowchart TB
    accTitle: Звужэнне пошуку па пропусках кадраў
    accDescr: Падчас дзеяння з абнаўленнем экрана параўноўваецца колькасць уваходных і выходных кадраў, і з дапамогай лічыльнікаў прычын пропуску вынікі супастаўляюцца з нагрузкай на апрацоўку, сетку і адлюстраванне.
    A["Параўнаць уваход і выхад пры пракрутцы"] --> B["Калі выхаду менш, праверыць пропускі"]
    B --> C["Глядзець лічыльнікі паводле прычын"]
    C --> D["Супаставіць з нагрузкай аддаленага ПК, сеткі і лакальнай прылады"]

Малюнак 15: Мы параўноўваем уваходныя і выходныя кадры падчас пракруткі і супастаўляем прычыны пропуску з нагрузкай на аддалены камп’ютар, канал і вашу прыладу.

Канцэптуальныя схемы перадачы экрана і старыя матэрыялы мы не абагульняем на ўсе канфігурацыі. Ёсць канфігурацыі, у якіх відэа і аўдыя перадаюцца праз іншыя механізмы. Матэрыялы пра лічыльнікі Graphics утрымліваюць і апісанні старых канфігурацый, таму пададзеныя там лічбы мы не пераінтэрпрэтуем як агульную спецыфікацыю накшталт «любы RDP — максімум 30 fps». Функцыі і лічбы мы выкарыстоўваем толькі пасля праверкі, да чаго яны адносяцца. Гл.: перадача экрана і тыпы нагрузкі, матэрыялы пра лічыльнікі Graphics.

Межы вынікаў вымярэнняў

Мы не атаясамліваем нізкае значэнне з камфортнай працай. Межы кожнага паказчыка можна праверыць у матэрыялах Microsoft, пададзеных у апісаных вышэй кроках.

Налады сеткі і GPU

Налады UDP і GPU выбіраюцца паводле таго, што высветлілася пры параўнаннях і вымярэннях. Калі пад падазрэннем сетка, спачатку правяраюцца спосаб падключэння і маршрут, а калі апрацоўка экрана — этап, на якім выкарыстоўваецца GPU.

Праверка TCP/UDP і маршруту падключэння

Калі параўнанні і вымярэнні паказваюць на сетку, разам з адміністратарам правяраюцца кліент, маршрут і палітыкі, якія дзейнічаюць. Нават калі патрэбна змена налад, яна робіцца толькі ў зацверджаных межах, а значэнні да змены і спосаб аднаўлення запісваюцца. Мы не адключаем брандмаўэр або аўтэнтыфікацыю і не адкрываем порт RDP наўпрост у інтэрнэт.

1. Праверце фактычныя TCP/UDP і маршрут па звестках пра падключэнне, дыягнастычных журналах прадукту і сеткавых запісах адміністратара.

   RDP выкарыстоўвае TCP або UDP у залежнасці ад канфігурацыі і ўмоў сеткі. У «Select RDP transport protocols» можна выбраць наладу з выкарыстаннем UDP або TCP і наладу толькі з TCP. Калі UDP-падключэнне не ўсталёўваецца, можа выкарыстоўвацца TCP, таму па адным толькі паспяховым падключэнні спосаб не вызначыць. Гл.: выбар RDP transport і пераход на запасны варыянт.

2. Супастаўце маршрут і спосаб з часам сімптому і параўноўвайце па адной толькі неабходныя налады.

   Не мяняйце налады паводле агульнага правіла «адключыш UDP — стане хутчэй». Параўноўвайце пры аднолькавых умовах VPN або шлюза, дзеяннях і ўмовах адлюстравання, а непатрэбныя змены вяртайце.

Ведаючы спосаб і маршрут, можна запісаць сувязь паміж зменамі і сімптомамі. Пераход толькі на TCP не заўсёды паскарае працу.

flowchart TB
    accTitle: Спачатку праверыць спосаб падключэння, потым параўноўваць сеткавыя налады
    accDescr: Звычайнае прамое падключэнне адрозніваецца ад падключэння праз шлюз або службу; фактычны маршрут і спосаб правяраюцца да таго, як праводзіцца дазволенае параўнанне.
    A["Кліент і канфігурацыя падключэння"] --> B["Праверыць фактычны маршрут і TCP/UDP"]
    B --> C["Супаставіць з часам сімптому"]
    C --> D["Параўноўваць па адной толькі патрэбныя налады"]

Малюнак 16: Мы высвятляем фактычны спосаб падключэння і маршрут, супастаўляем іх з сімптомам і толькі потым параўноўваем патрэбныя налады.

RDP Shortpath — гэта механізм Azure Virtual Desktop. Ён усталёўвае UDP-маршрут гэтай службы і ў залежнасці ад канфігурацыі выкарыстоўвае прамы маршрут або рэтрансляцыю. Калі ўсталяваць яго не ўдаецца, адбываецца вяртанне да падключэння на аснове TCP. Звесці яго ў адну табліцу налад з выпадкам прамога падключэння да офіснага ПК праз mstsc нельга. Гл.: маршруты RDP Shortpath і пераход на запасны варыянт.

flowchart TB
    accTitle: Маршруты RDP Shortpath і пераход на запасны варыянт
    accDescr: RDP Shortpath у Azure Virtual Desktop спрабуе ўсталяваць UDP-маршрут; калі гэта ўдаецца, у залежнасці ад канфігурацыі выкарыстоўваецца прамы маршрут або рэтрансляцыя, а калі не, адбываецца вяртанне да падключэння на аснове TCP.
    A["RDP Shortpath"] --> B{"UDP-маршрут"}
    B -->|"Усталяваны"| C["Прамы або праз рэтрансляцыю"]
    B -->|"Не ўсталяваны"| D["Вяртанне да TCP"]

Малюнак 17: Калі UDP-маршрут усталяваць не ўдаецца, RDP Shortpath вяртаецца да падключэння на аснове TCP.

Праверка выкарыстання GPU для апрацоўкі экрана

Гэта праверка праводзіцца, калі параўнанні і вымярэнні паказваюць на апрацоўку экрана. Правяраюцца вынікі вымярэння апрацоўкі экрана, а таксама падтрымліваемыя АС, драйверы, палітыкі і кліент. Адна толькі наяўнасць GPU не падстава мяняць налады. Спачатку атрымліваецца згода адміністратара і рыхтуецца спосаб вярнуць зыходны стан.

1. Раздзяліце адмалёўку праграмы на аддаленым камп’ютары, кадзіраванне RDP і дэкадзіраванне на вашым баку і выберыце этап, які выклікае падазрэнне.

   Нават калі GPU ёсць, не ўсе этапы абавязкова яго выкарыстоўваюць. У матэрыялах Microsoft па канфігурацыі Azure Virtual Desktop адмалёўка ў аддаленым сеансе і апаратнае кадзіраванне кадраў таксама наладжваюцца і правяраюцца асобна. Гл.: канфігурацыя і праверка GPU для адмалёўкі і кадзіравання.

2. Праверце фактычнае выкарыстанне паводле інструкцый патрэбнага прадукту і вымярайце тое ж дзеянне да і пасля неабходнай змены.

   Калі час сціскання доўгі, даследуйце выкарыстанне GPU для кадзіравання. Калі праграма чакае ў чарзе ўводу, змена налад кадзіравання накіравана не туды. Для чытэльнасці тэксту і плаўнасці відэа баланс паміж якасцю выявы, аб’ёмам трафіку і нагрузкай на апрацоўку таксама выбіраецца па-рознаму. Гл.: адрозненні паводле тыпу нагрузкі.

Можна запісаць не толькі наяўнасць GPU, але і тое, ці выкарыстоўваецца GPU на праблемным этапе і як змяніліся нагрузка і водгук для таго ж дзеяння. Змены, якія не далі паляпшэння, вяртаюцца пасля ўзгаднення з адміністратарам.

flowchart TB
    accTitle: Праверка выкарыстання GPU па этапах
    accDescr: Адмалёўка праграмы на аддаленым камп'ютары, кадзіраванне RDP і лакальнае дэкадзіраванне разглядаюцца асобна; паколькі нават пры наяўнасці GPU не ўсе этапы абавязкова яго выкарыстоўваюць, правяраецца выкарыстанне на этапе пад падазрэннем.
    A["Адмалёўка праграмы на аддаленым ПК"] --> B["Кадзіраванне RDP"]
    B --> C["Лакальнае дэкадзіраванне"]
    C -.- D["Праверыць GPU на кожным этапе"]

Малюнак 18: Нават пры наяўнасці GPU не ўсе этапы — адмалёўка, кадзіраванне і дэкадзіраванне — абавязкова яго выкарыстоўваюць.

Паўторная праверка і перадача расследавання

Паляпшэнне пацвярджаецца тым, што пасля змены тое ж дзеянне выконваецца без праблем і пры гэтым захоўваюцца неабходныя якасць выявы, прылады і працоўныя функцыі. Супастаўце таксама вынік пасля вяртання зыходных умоў. Калі аднаўленне было толькі мімалётным, прычына не лічыцца ўсталяванай, і ў запіс трапляюць таксама гадзіны пік і паралельныя працэсы.

flowchart TB
    accTitle: Парадак праверкі паляпшэння
    accDescr: Паказана, што пасля змены правяраецца, ці выконваецца тое ж дзеянне без праблем і ці захоўваюцца неабходныя якасць выявы, прылады і працоўныя функцыі, вынік супастаўляецца з вынікам пасля вяртання зыходных умоў, а мімалётнае аднаўленне не дазваляе ўсталяваць прычыну.
    A["Пасля змены паспрабаваць тое ж дзеянне"] --> B["Праверыць якасць, прылады і функцыі"]
    B --> C["Супаставіць з вынікам пасля вяртання"]
    C -.- D["Мімалётнае аднаўленне нічога не даказвае"]

Малюнак 19: Акрамя выніку таго ж дзеяння, супастаўляюцца неабходныя функцыі і вынік пасля вяртання.

Перадача, калі праблема не вырашана

Калі паляпшэння няма, праблема не ўзнаўляецца або лічыльнікі недаступныя, гэта таксама карысныя вынікі. Мы раздзяляем параўнанні, якія ўдалося правесці, і праверкі, якія правесці не ўдалося, і перадаём справу адміністратару або распрацоўшчыку з дапамогай нататкі ніжэй. Выдаліце з агульных журналаў працоўныя звесткі, непатрэбныя для расследавання, такія як імёны карыстальнікаў і адрасы падключэння.

Час з'яўлення сімптому і часавы пояс:
АС аддаленага камп'ютара, кліент і яго версія:
Прамое падключэнне / VPN / RD Gateway / Azure Virtual Desktop і інш.:
Павольнае дзеянне і праграма, водгук іншых праграм у тым жа сеансе:
Раздзяляльнасць на аддаленым баку і колькасць манітораў:
Капіяванне, друк і іншае, што выконвалася адначасова:
Адзіная змененая ўмова і вынік пасля вяртання:
Нагрузка і лічыльнікі, назіраныя на аддаленым і лакальным баку:

Мы таксама дадаём, ці ўдалося праверыць фактычныя TCP/UDP, якія пункты не ўдалося праверыць з-за недахопу правоў і г. д., і якія налады дапушчальныя для працы. Калі паведаміць «у Notepad тэкст набіраецца нармальна, але пры пракрутцы фотаздымкаў усё замірае», а не «канал павольны», наступны адказны зможа даследаваць праблему пры тых жа ўмовах.

Карыстальнік фіксуе дзеянне, якое ўзнаўляе праблему, і вынікі параўнанняў, а адміністратар супастаўляе запісы пра маршрут падключэння, агульны хост і сеансы. Адзін толькі факт чакання ў RDP не азначае, што працэс, які выклікае чаканне, — таксама RDP. Гл.: падзел роляў паміж хостам і бэкендам.

Распрацоўшчыкі праграмы асобна запісваюць прыём падзей уводу, пачатак і канец работы з БД і файламі і адлюстраванне ў UI. Яны таксама разглядаюць архітэктуру, у якой цяжкая праца не затрымліваецца ў UI-патоку. Аднак журнал аб завяршэнні апрацоўкі на аддаленым камп’ютары не фіксуе завяршэння адлюстравання на вашым баку. Гл.: аддзяленне апрацоўкі для захавання хуткасці водгуку UI.

Звязаныя артыкулы

• Як разумець ізаляцыю сеансаў у Windows
• Як бяспечна высветліць прычыну 100% загрузкі дыска ў Windows
• Чаму «засталася 1 секунда» ніяк не сканчаецца?

Крыніцы

Гэта першасныя матэрыялы Microsoft Learn. Змест спасылак правераны 17 верасня 2026 г. Чытаючы іх, адрознівайце ўмовы прымянення для кожнага прадукту і ўлічвайце, што гэта не вымярэнні, праведзеныя ў рамках гэтага артыкула.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. Адрозненне паміж RTT і затрымкай ад захопу экрана на аддаленым камп’ютары да адлюстравання на вашым баку. Самі дыягнастычныя функцыі прызначаны для Azure Virtual Desktop.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. Сувязь змесціва экрана, раздзяляльнасці, абнаўлення кадраў, сціскання і кэшавання з аб’ёмам трафіку.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. Як правяраць уваходныя і выходныя кадры экрана, прычыны пропуску і час кадзіравання. Паколькі матэрыял утрымлівае апісанні старых канфігурацый, лікавыя абмежаванні мы не абагульняем на ўвесь RDP.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. Нагрузка на агульны хост, сувязь ад аддаленага камп’ютара да бэкенда, уплыў перанакіравання прылад.
• Microsoft Learn, Threading model. UI-паток і Dispatcher у WPF, аддзяленне апрацоўкі для захавання хуткасці водгуку.
• Microsoft Learn, mstsc. Заданне шырыні і вышыні аддаленага працоўнага стала і некалькіх манітораў.
• Microsoft Learn, Supported RDP properties. Адрозненне паміж раздзяляльнасцю працоўнага стала, дынамічнай раздзяляльнасцю і smart sizing. Падтрымліваемыя кліенты і ўмовы прымянення правяраюцца для кожнага прадукту.
• Microsoft Learn, ping. Праверка адказу з дапамогай ICMP Echo і параметры.
• Microsoft Learn, Test-NetConnection. Праверка TCP-падключэння і сэнс вываду.
• Microsoft Learn, Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts. Вымяраны ўчастак User Input Delay, падтрымліваемыя АС, экзэмпляры, сэнс максімальнага значэння.
• Microsoft Learn, query session. Звесткі пра сеансы і правы, неабходныя для запыту іншых сеансаў.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. Выбар TCP або UDP, якія выкарыстоўвае RDP, і пераход на запасны варыянт.
• Microsoft Learn, RDP Shortpath. UDP-маршрут для Azure Virtual Desktop і паводзіны, калі яго не ўдаецца ўсталяваць.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. Канфігурацыя і праверка GPU асобна для адмалёўкі і кадзіравання кадраў.

Звязаныя артыкулы

Апошнія артыкулы з такімі ж тэгамі. Паглыбляйце веды на блізкіх тэмах.

Звязаныя тэмы

Гэта тэматычныя старонкі, блізкія да гэтай тэмы. Ад артыкула можна перайсці да звязаных паслуг і іншых артыкулаў.

Паслугі, з якімі звязана гэтая тэма

Гэты артыкул вядзе да наступных старонак паслуг. Пачніце з бліжэйшай.

Частыя пытанні

Частыя пытанні падчас кансультацый па тэме гэтага артыкула.

Чаму ўвод у RDP павольны, хоць тэст хуткасці паказвае сотні Мбіт/с?

Хуткасць перадачы вялікіх аб'ёмаў даных і час, за які вяртаецца водгук на дзеянне, — розныя рэчы. Тут адыгрываюць ролю адпраўка ўводу, апрацоўка ў праграме на аддаленым камп'ютары, сцісканне выявы экрана, перадача і адлюстраванне на вашым баку. Акрамя таго, маршрут да сервера тэсту хуткасці і маршрут да аддаленага камп'ютара RDP розныя.

Тэкст набіраецца нармальна, а рыўкамі ідзе толькі пракрутка. Гэта праблема канала?

Звесці ўсё толькі да канала нельга. Калі абнаўленняў экрана становіцца больш, можа не паспяваць адмалёўка і сцісканне на аддаленым камп'ютары, сеткавая перадача або дэкадзіраванне і адлюстраванне на вашым баку. Мы мяняем па адной раздзяляльнасць на аддаленым баку або колькасць манітораў і параўноўваем, а пры неабходнасці правяраем лічыльнікі, звязаныя з адмалёўкай.

Калі ping хуткі, значыць, сеткавая частка RDP у парадку?

Толькі па гэтым меркаваць нельга. ping вымярае адказ на ICMP і не вымярае ні перадачу экрана RDP, ні апрацоўку ў праграме. У канфігурацыях з RD Gateway і падобнымі маршрут таксама можа не супадаць. Калі адказу няма, таксама адрознівайце блакіроўку ICMP ад недаступнасці самога RDP.

User Input Delay — гэта час ад націскання клавішы да з'яўлення сімвала?

Не. Гэта лічыльнік, які вымярае час чакання ад моманту, калі ўвод трапляе ў чаргу на аддаленым камп'ютары, да моманту, калі працэс яго адтуль забірае. Гэта не адчувальная затрымка, якая ўключала б перадачу туды і назад, апрацоўку ў праграме пасля таго, як увод забраны, а таксама сцісканне, дэкадзіраванне і адлюстраванне экрана.

Ці трэба адключаць UDP, калі RDP тармозіць?

Як агульную меру мы гэтага не раім. Спачатку мы правяраем фактычны спосаб падключэння, маршрут і палітыкі, якія дзейнічаюць. Магчыма, UDP недаступны і падключэнне ўжо перайшло на TCP, а пераход толькі на TCP не заўсёды робіць працу хутчэйшай. З дазволу адміністратара мы параўноўваем пры аднолькавых умовах, а непатрэбныя змены вяртаем назад.

Профіль аўтара

Старонка з профілем аўтара артыкула.

Го Комура

Прадстаўнік KomuraSoft LLC

Займаецца распрацоўкай ПЗ для Windows, тэхнічнымі кансультацыямі і расследаваннем дэфектаў; асабліва моцны ў праектах з наяўнымі распрацоўкамі і ў пошуку прычын збояў, якія цяжка выявіць.