למה RDP איטי כשהחיבור מהיר? — לבדוק בנפרד input, rendering ורשת

בדיקת המהירות מראה כמה מאות Mbps, אבל ב-Remote Desktop התווים מופיעים באיחור קל. כשגוללים בדף עם הרבה תמונות, המסך נתקע לרגע. רק כשלוחצים על חיפוש באפליקציה העסקית, הכול עוצר לכמה שניות. מאיפה מתחילים לחקור מצב כזה של “החיבור מהיר אבל RDP איטי”?

מהירות התגובה של RDP לפעולות לא נקבעת רק לפי מהירות ההעברה של הקו. גם כשבדיקת המהירות מראה תוצאה גבוהה, ההמתנה יכולה להיווצר ב-round trip ברשת, בהמתנה ל-input באפליקציה ב-host, ב-encoding של המסך, או ב-decoding ובהצגה במחשב שלכם. קודם הפרידו “איזו פעולה איטית”, ואז השוו את אותה פעולה כשאתם משנים תנאי אחד בכל פעם. בעזרת ההשוואות והמדידות מצמצמים את המקום שצריך לחקור, ואת הגדרות ה-UDP וה-GPU בוחרים לפי התוצאות. ראו: קטעי המדידה של איכות החיבור, גורמי ביצועים ב-session host.

עם זאת, גם אחרי שצמצמתם את המקום לחקירה, ה-root cause עדיין לא נקבע. אם הורדת ה-resolution שיפרה את המצב, לא קובעים ש”הקו היה הבעיה”, כי משתנה לא רק התקשורת אלא גם עיבוד המסך בשני הקצוות. מתעדים את התוצאות ומפרידים בין הקטעים שנמדדו לבין אלה שלא נמדדו.

המאמר עוסק בבידוד של input, scroll ותגובת אפליקציות אחרי שהחיבור כבר קיים. גם כשהסימפטומים דומים, הסיבה לא בהכרח אחת. מקרים כמו “לוקח הרבה זמן עד שמסך ההתחברות מופיע” או “זה נתקע רק באימות” הם בעיה אחרת, שחוקרים דרך הרשומות של הקמת החיבור והאימות.

קהל היעד העיקרי הוא משתמשים ו-admins שמתחברים מהאפליקציה “Remote Desktop Connection” של Windows (mstsc) אל Windows 11 או Windows Server. דוגמאות הפקודות מיועדות ל-Windows PowerShell 5.1. ההנחה היא שאפשר לשחזר את אותה פעולה ב-session מחובר.

בחיבור ישיר, ב-VPN, ב-RD Gateway וב-Azure Virtual Desktop, הנתיב, מידע האבחון הזמין והמקום שבו ההגדרות חלות שונים. דוגמת הבדיקה של TCP 3389 מתאימה רק לחיבור ישיר ומורשה ל-RDP host שמשתמש בפורט הסטנדרטי. את יכולות האבחון ואת הגדרות ה-GPU מהתיעוד של Azure Virtual Desktop לא מחילים כמו שהם על מחשבים רגילים בארגון.

במחשבים של החברה חוקרים רק במסגרת שה-admin אישר. ב-host משותף, זהו את ה-session שלכם ואת ה-process הרלוונטי, ואם צריך נתונים של משתמשים אחרים, בקשו אותם מה-admin. את הזמינות של performance counters, את שמות התצוגה שלהם ואת ההרשאות הנדרשות בודקים בכל סביבה בנפרד.

שיטות הבדיקה כאן מבוססות על התיעוד הרשמי. זה לא דיווח על מדידה בפועל שבה שוחזרה תקלה במחשב מסוים ונפתרה. דוגמאות מספריות מסומנות בנפרד כהנחות לצורך ההסבר.

את המנגנון אפשר לקרוא לפי הסדר, החל מהפרק הבא, “מהירות העברה ו-round-trip time”. אם אתם רוצים להתחיל מהסימפטום, עברו לפרק “ההשוואה הראשונה לפי הסימפטום”. תהליכי העבודה נמצאים בפרקים “השוואה של תנאי אחד בכל פעם” ו”למדוד איפה מחכים”.

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 7, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

מהירות העברה ו-round-trip time

RDP (Remote Desktop Protocol) הוא פרוטוקול שמעביר input, מידע על המסך ונתונים נוספים בין המחשב שלכם לבין ה-host. הוא מטפל לא רק במסך וב-input, אלא גם במידע של device redirection, הדפסה ועוד. ראו: המידע ש-RDP מעביר.

מהירות ההעברה של הקו מתארת כמה data אפשר להעביר בשנייה. ה-“500Mbps” בבדיקת המהירות הוא מספר שמתייחס לכמות הזו. הוא לא מציין כמה זמן עובר מרגע הפעולה ועד שהתגובה מגיעה. ראו: דרישות רוחב הפס של RDP.

flowchart TB
    accTitle: מה המספר של בדיקת המהירות מייצג
    accDescr: ה-500Mbps של בדיקת המהירות הוא מספר שמייצג את כמות ה-data שאפשר להעביר בשנייה, וזה מספר אחר מהזמן מרגע הפעולה ועד שהתגובה מגיעה.
    A["בדיקת מהירות: 500Mbps"] --> B["כמות data לשנייה"]
    B -.->|"מספר אחר"| C["הזמן עד שהתגובה מגיעה"]

איור 1: המספר של בדיקת המהירות מייצג את הכמות שאפשר להעביר, ולא את הזמן עד שהתגובה מגיעה.

Round-trip time (RTT) הוא הזמן שלוקח לתקשורת להגיע לצד השני ולחזור. ההבדל בין הגדלת מהירות ההעברה לבין קיצור ה-round-trip time דומה להבדל בין הוספת נתיבים לכביש לבין קיצור המרחק ליעד. גם אם היכולת להעביר כמויות גדולות של קבצים גדלה, כל עוד ה-round-trip time לא השתנה, ההמתנה לתגובה על פעולה נשארת. ראו: RTT ו-delay בהצגת המסך.

flowchart TB
    accTitle: מהירות העברה ו-round-trip time כמשל לכביש
    accDescr: תרשים שמשווה הגדלת מהירות ההעברה להוספת נתיבים לכביש, וקיצור ה-round-trip time לקיצור המרחק ליעד.
    A["הגדלת מהירות ההעברה"] -->|"בכביש"| B["עוד נתיבים"]
    B ~~~ C["קיצור ה-round-trip time"]
    C -->|"בכביש"| D["מרחק קצר יותר"]

איור 2: הוספת נתיבים לא מקצרת את המרחק ליעד.

עד שהתוצאה של תו אחד חוזרת

נניח שמקלידים תו אחד ב-Notepad המרוחק. Notepad רץ ב-host. לצורך ההסבר, אם מניחים 50 מילישניות עד שהפעולה מגיעה ו-50 מילישניות עד שמידע המסך עם התוצאה חוזר, זמן התקשורת הכולל הוא 100 מילישניות, כלומר 0.1 שנייה. זמני העיבוד בשני הקצוות לא נכללים בדוגמה הזו.

flowchart TB
    accTitle: דוגמה לזמן התקשורת עד שהתוצאה של תו אחד חוזרת
    accDescr: דוגמה לצורך ההסבר שבה מניחים 50 מילישניות לכל כיוון. זמני העיבוד בשני הקצוות לא נכללים, והתרשים לא מייצג את מספר ה-packets לכל מקש.
    A["הקלדת תו אחד אצלכם"] -->|"הלוך: 50 מילישניות"| B["ה-host מקבל את ה-input"]
    B --> C["שליחת המסך המעודכן"]
    C -->|"חזור: 50 מילישניות"| D["התוצאה מגיעה אליכם"]

איור 3: אם הלוך לוקח 50 מילישניות וחזור 50 מילישניות, התקשורת לבדה לוקחת 0.1 שנייה. אלה לא ערכים שנמדדו.

גם אם הקו יכול להעביר יותר, כל עוד ה-round-trip time לא משתנה, ה-0.1 שנייה האלה נשארות. איור 3 הוא תרשים עקרוני שנועד להבין את התהליך. הוא לא אומר שלכל מקש נשלח round trip נפרד של packets. גם הנתיב לשרת של בדיקת המהירות שונה מהנתיב ל-RDP host, ולכן לוקחים בחשבון VPN, gateways, את ה-upload בצד ה-host ועומס בדרך. ראו: איך לחשוב על RTT, ביצועי הרשת וה-host.

בניית המסך והעברתו

עיכוב בתגובה לפעולה, במובן שבו הוא משמש כאן, הוא ההמתנה מרגע שביצעתם פעולה אצלכם ועד שאתם רואים את התוצאה. מעורבים בו לא רק ה-RTT, אלא גם העיבוד של האפליקציה והתהליך שבונה את המסך ומעביר אותו. מבדילים אותו גם מה-delay של קטע העברת המסך בלבד. ראו: קטע המדידה מלכידת המסך ועד ההצגה.

כשה-input מגיע מהמחשב שלכם ל-host, האפליקציה ב-host מעבדת אותו ומעדכנת את המסך, מידע המסך עובר encoding ומועבר בקו, ובצד שלכם הוא עובר decoding ומוצג. גם לפני התקשורת וגם אחריה יש עבודה, ושני מחשבים שונים אחראים עליה. ראו: העיבוד מלכידת המסך ועד ההצגה.

flowchart TB
    accTitle: גם לפני הקו ואחריו יש עיבוד של המסך
    accDescr: התהליך שבו ה-input מהמחשב שלכם מגיע ל-host, האפליקציה ב-host מעבדת אותו, בונה את המסך ודוחסת אותו, ומידע המסך שעבר בקו מוחזר אצלכם לצורה שאפשר להציג ומוצג.
    I["אצלכם: הזנת פעולה"] --> J["קו: העברת ה-input"]
    J --> K["Host: האפליקציה מעבדת"]
    K --> A["Host: בניית המסך ודחיסה"]
    A --> B["קו: העברת מידע המסך"]
    B --> C["אצלכם: החזרה לצורה מוצגת"]
    C --> D["הצגה על המסך שלכם"]

איור 4: עיבוד ודחיסה ב-host, העברה בקו, והחזרה לתצוגה אצלכם. כל אחת מהעבודות האלה מתבצעת במקום אחר.

ב-encoding הכוונה במאמר הזה לעיבוד שממיר ודוחס ב-host את המסך לצורה שקל לשלוח. בנוסף להעברה בקו, העיבוד הזה לוקח זמן ב-host. ראו: זמן ה-encoding ב-host.

ב-decoding הכוונה במאמר הזה לעיבוד שמחזיר אצלכם את מידע המסך שהגיע לצורה שאפשר להציג. זה לא אותו דבר כמו פענוח הצפנה (decryption). ראו: זמן ה-decoding וההצגה אצלכם.

אם הדחיסה ב-host לוקחת זמן, גם כשהקו פנוי מחכים שהנתונים יהיו מוכנים לשליחה. גם כשהמידע כבר הגיע, אם ה-decoding או ההצגה אצלכם לא עומדים בקצב, העדכון מתעכב. “המחשב בעבודה חזק, אז לא משנה מה יש אצלי” לא תמיד נכון. המרווח בקו והמרווח בעיבוד בשני הקצוות שלו הם שני דברים נפרדים. ראו: performance counters של עיבוד המסך.

flowchart TB
    accTitle: עיכוב כששני הקצוות לא עומדים בקצב
    accDescr: אם הדחיסה ב-host לוקחת זמן, מחכים להכנת השליחה גם כשהקו פנוי, ואם ה-decoding או ההצגה אצלכם לא עומדים בקצב, העדכון מתעכב גם כשהמידע כבר הגיע.
    A["הדחיסה ב-host לוקחת זמן"] --> B["מחכים לשליחה גם כשהקו פנוי"]
    B ~~~ C["ה-decoding אצלכם לא עומד בקצב"]
    C --> D["העדכון מתעכב גם כשהמידע הגיע"]

איור 5: גם כשיש מרווח בקו, אם העיבוד בשני הקצוות לא עומד בקצב, עדכון המסך מתעכב.

הקלדה לעומת scroll

כשמוסיפים תו אחד ב-Notepad, רק חלק קטן מהמסך משתנה. כשגוללים בדף עם הרבה תמונות, אזור גדול בתצוגה משתנה שוב ושוב. RDP מצמצם את כמות התקשורת בכך שהוא מעביר את החלקים שהשתנו ומשתמש בדחיסה וב-caching שמתאימים לתוכן. הוא לא שולח בכל פעם את כל המסך בלי דחיסה. כמות העבודה משתנה לפי תוכן המסך ותדירות העדכונים. ראו: הקשר בין תוכן המסך לרוחב הפס.

flowchart TB
    accTitle: כמות העבודה על המסך בהקלדה וב-scroll
    accDescr: לשינוי קטן של תו ולעדכון רציף של אזור גדול יש אופי שונה של עבודת בניית המסך ושליחתו.
    A{"שינוי במסך"} -->|"הוספת תו"| B["אזור קטן"]
    A -->|"Scroll"| D["אזור גדול ברציפות"]
    B --> E["דחיסה והעברה לפי השינוי"]
    D --> E

איור 6: גם באותו חיבור, כמות העבודה שונה כשמוסיפים תו אחד וכשאזור גדול זז ברציפות.

גם אם מסמך סטטי לא מעמיס, בזמן scroll העברת המסך עלולה להישאר בלי מרווח. כשמגדילים את ה-resolution או את מספר המסכים בצד המרוחק, גם המסך שצריך לעבד גדל. השוואה עם resolution נמוך יותר היא ניסוי שבודק אם התנועה חוזרת להיות חלקה כשמקטינים את העבודה של בניית המסך ושליחתו. זה לא חישוב שקובע את כמות התקשורת לפי מספר ה-pixels בלבד. ראו: ההשפעה של resolution, עדכוני מסך ודחיסה.

המתנות של האפליקציה

אם רק החיפוש באפליקציה העסקית נתקע לכמה שניות, ובאותו session אפשר להקליד ב-Notepad כרגיל, בודקים למה האפליקציה הזו מחכה. ייתכן שהאפליקציה ב-host שולחת שאילתה ל-DB אחר או קוראת קובץ מתיקייה משותפת, וממתינה לתשובה. זה נתיב נפרד מתקשורת ה-RDP שמחברת בין המחשב שלכם ל-host. ראו: התקשורת מה-host ל-backend.

flowchart TB
    accTitle: גם מעבר ל-RDP יש צדדים נוספים בתקשורת
    accDescr: מציג מצב שבו, בנוסף לתקשורת בין המחשב שלכם ל-host, האפליקציה ב-host מחכה לתשובה משרת עסקי.
    A["המחשב שלכם"] -->|"RDP"| B["האפליקציה העסקית ב-host"]
    B -->|"חיפוש ובקשת קבצים"| C["DB ותיקייה משותפת"]
    C -->|"התשובה שמחכים לה"| B

איור 7: האפליקציה העסקית שמעבר ל-RDP עשויה לחכות לתשובה משרת נוסף.

כשהקוד שאחראי על המסך ועל ה-input עסוק בעבודה ארוכה, ה-input הבא ועדכון המסך הבא מתעכבים. למשל ב-WPF, כשה-UI thread תפוס לאורך זמן, התגובתיות נפגעת. ניצולת CPU כוללת נמוכה לבדה לא שוללת המתנה ב-UI thread מסוים. ראו: Dispatcher וה-UI thread.

flowchart TB
    accTitle: הקוד שאחראי על המסך וה-input נחסם
    accDescr: כשהקוד שאחראי על המסך וה-input עסוק בעבודה ארוכה, ה-input ועדכון המסך הבאים מתעכבים, וניצולת CPU כוללת נמוכה לבדה לא שוללת את ההמתנה הזו.
    A["הקוד שאחראי על המסך וה-input"] --> B["עסוק בעבודה ארוכה"]
    B --> C["ה-input ועדכון המסך הבאים מתעכבים"]
    C -.- D["CPU כולל נמוך לא שולל את זה"]

איור 8: ניצולת ה-CPU הכוללת לבדה לא שוללת המתנה ב-UI thread.

ההשוואה הראשונה לפי הסימפטום

הכמות שאפשר להעביר, הזמן שמחכים לתשובה, והזמן לבנות את המסך ולהציג אותו הם שלושה דברים שונים. אם שומרים על ההפרדה הזו, לא מסבירים את “RDP איטי” בסיבה אחת, ואפשר להתחיל לחקור מהפעולה שאיטית עכשיו.

flowchart TB
    accTitle: מפרידים לשלושה ואז חוקרים
    accDescr: מראה שלא מסבירים את 'RDP איטי' בסיבה אחת, אלא מפרידים בין הכמות שאפשר להעביר, הזמן שמחכים לתשובה והזמן לבנות ולהציג את המסך, וחוקרים מהפעולה שאיטית עכשיו.
    A["'RDP איטי'"] --> S
    subgraph S["בודקים בנפרד"]
    direction TB
    B["כמות שאפשר להעביר"] ~~~ C["זמן המתנה לתשובה"]
    C ~~~ D["זמן לבנות ולהציג מסך"]
    end
    S --> E["חוקרים מהפעולה האיטית עכשיו"]

איור 9: אם מפרידים בין הכמות שאפשר להעביר, הזמן שמחכים לתשובה והזמן לבנות ולהציג את המסך, אפשר לחקור מהפעולה שאיטית עכשיו.

המטרה של הבידוד היא לצמצם את המקום שבו חוקרים את האיטיות. המטרה היא לא לשנות הרבה הגדרות בבת אחת ולקבל מהירות במקרה. אם משתמשים בהבדלים כמו “Notepad עובד אבל רק החיפוש נתקע” או “הקלדה רגילה אבל רק ה-scroll כבד”, אפשר לבחור מאיפה להתחיל לחקור עוד לפני ששינו הגדרות רשת.

הטבלה הבאה היא נקודת פתיחה לחקירה. היא לא טבלה שקובעת את הסיבה. קודם משווים פעולות באותו session, ורק אחר כך משנים, לפי הצורך, את המחשב, את הנתיב או את תנאי התצוגה.

תווים מתעכבים בכמה אפליקציות

אם בכמה אפליקציות באותו session כל תו מתעכב, משווים את אותה פעולה גם ממחשב אחר או בנתיב מורשה אחר. מצליבים את ה-round-trip time, ההמתנה ל-input ב-host והעומס הכולל על ה-host, ולא קובעים את הסיבה לפי מספר אחד.

רק ה-scroll מקרטע

גם כשההקלדה רגילה, scroll בדף עם הרבה תמונות יוצר עדכונים רצופים של אזור גדול במסך. משנים את ה-resolution או את מספר המסכים בצד המרוחק, אחד בכל פעם, ומשווים על אותו דף. אם המצב השתפר, הדחיסה ב-host, העברת המסך וה-decoding אצלכם הם הדברים הבאים לחקור. ה-resolution לבדו לא מראה איזה משלושת אלה הוא הסיבה. ראו: העומס לפי תוכן המסך וה-resolution.

רק אפליקציה אחת נתקעת

אם רק האפליקציה העסקית שבה לחצתם על חיפוש נתקעת, בודקים אם Notepad או אפליקציה אחרת באותו session מגיבים. אם אפליקציה אחרת עובדת, חוקרים קודם את העיבוד של האפליקציה הבעייתית, את הדיסק ואת הבקשות ל-DB או לתיקייה המשותפת. זה שאתם עובדים דרך RDP לא אומר שתקשורת ה-RDP היא הסיבה להמתנה. ראו: גורמי ביצועים של אפליקציות ו-backend.

כולם איטיים רק כשיש יותר משתמשים

אם כמה משתמשים חווים איטיות באותן שעות, בודקים עם ה-admin מה המצב ב-sessions האחרים. מצליבים את העומס על ה-CPU, הזיכרון וה-storage של ה-host המשותף ועל הקו המשותף עם זמני הסימפטום. לא ניגשים בלי אישור לנתונים או לעיבודים של משתמשים אחרים, ולא עוצרים jobs. ראו: המשאבים של host משותף ומספר המשתמשים.

האטה בזמן העתקה או הדפסה

אם הבעיה מתחילה באותו זמן שבו התחלתם העתקה או הדפסה, עוצרים זמנית רק העברות שמותר לכם לעצור, ומשווים. מתעדים אם המצב חוזר לקדמותו אחרי העצירה ואם הוא מאט שוב כשממשיכים, ובודקים התנגשות עם העברות שאינן של המסך או עם device redirection. לא משווים על ידי ביטול גורף של התקנים שנחוצים לעבודה. ראו: ההשפעה של device redirection.

השוואה של תנאי אחד בכל פעם

אין צורך לשנות את כל ההגדרות אחת אחרי השנייה. קודם קובעים baseline להשוואה, ובוחרים רק את הבדיקות שמתאימות לסימפטום. לפני שינוי הגדרות או חיבור מחדש, שמרו את העבודה ותעדו את הערכים המקוריים ואיך מחזירים אותם. אם אין לכם את ההרשאות או היכולות הנדרשות, לא מנסים להפעיל אותן בכוח, אלא מעבירים את הנושא ל-admin.

עבודה מקומית ועבודה דרך RDP לא בהכרח מתבצעות באותם תנאים. זה שהמחשב מהיר כשעובדים מול המסך הפיזי שלו נותן כיוון, אבל ה-session ותנאי ה-rendering עשויים להיות שונים. השוו את המשתמש, ה-data ומצב האפליקציה, ואל תצמצמו את הסיבה לקו רק כי “מול המסך הפיזי זה מהיר”.

השוואה של אותה פעולה

מכינים את אותו משתמש, אותו data ואותה פעולה. ב-host משותף מוודאים איזה session הוא שלכם, ולא עוצרים אפליקציות או processes של משתמשים אחרים. גם שימוש במחשב אחר או בנתיב אחר מוגבל למה שה-admin אישר.

1. משחזרים את הפעולה האיטית עם ההגדרות המקוריות, ומתעדים את השעה ואת הסימפטום.

   מקלידים כמות דומה של טקסט ב-Notepad, באותו session מרוחק שבו נמצאת האפליקציה הבעייתית. כך מבחינים אם מדובר באפליקציה אחת בלבד או ב-session כולו.

2. בודקים את העומס ב-host ובמחשב שלכם באותו פרק זמן.

   ב-Task Manager בודקים ב-host את ה-CPU, הזיכרון והדיסק של האפליקציה הרלוונטית, ובמחשב שלכם את העומס של ה-RDP client. מסתכלים על ה-process הרלוונטי ולא רק על ערך ה-CPU הכולל. ראו: על מה בודקים עומס.

3. משנים רק תנאי אחד מתוך: מחשב אחר, נתיב מורשה אחר או תנאי התצוגה, וחוזרים על אותה פעולה.

   אם בהשוואה משתנים במקביל גם ה-host או מצב האפליקציה, מתעדים גם את ההבדל הזה. תוצאה שבה השתנו כמה תנאים לא נחשבת להשפעה של תנאי אחד בלבד.

4. מחזירים את התנאים למצב המקורי ובודקים שוב את אותה פעולה.

   אם גם אחרי ההחזרה המצב נשאר מהיר, ייתכן שהיה שינוי זמני בעומס או משהו דומה. לא מניחים שהשינוי הוא שעזר, ומתעדים את התנאים שבהם הסימפטום חוזר.

כך יש לכם תוצאות מהמצב המקורי, אחרי השינוי ואחרי ההחזרה, ואפשר להשוות איזה תנאי מתאים לאיזה סימפטום. תנאי ששיפר את המצב הוא רמז לחקירה, ולבדו הוא לא הוכחה ל-root cause.

flowchart TB
    accTitle: מגבילים את התנאים שמשתנים בכל פעם
    accDescr: התהליך: קובעים פעולה שמשחזרת את הבעיה במצב המקורי, משנים תנאי אחד בלבד ומשווים, ובודקים גם את התוצאה אחרי ההחזרה.
    A["אותה פעולה בהגדרות המקוריות"] --> B["משנים תנאי אחד בלבד"]
    B --> C["חוזרים על אותה פעולה"]
    C --> D["מחזירים ובודקים שוב"]
    D --> E["מתעדים את התנאי ששיפר"]

איור 10: חוזרים על אותה פעולה במצב המקורי, אחרי השינוי ואחרי ההחזרה, ומתעדים את התנאי שהשתנה.

השוואת ה-resolution בצד המרוחק

משווים כשעדכוני המסך כבדים, למשל ב-scroll. מתעדים את ה-resolution ואת מספר המסכים לפני השינוי, שומרים את העבודה ומתחברים מחדש. לא משאירים לשימוש קבוע הגדרה שפוגעת במסכים שנחוצים לעבודה או בקריאוּת הטקסט.

1. משנים רק אחד מהשניים: מספר המסכים או ה-resolution.

   ב-mstsc אפשר להשוות דרך ההגדרות בלשונית Display לפני החיבור, או דרך ציון רוחב וגובה. ראו: הגדרות המסך של mstsc.

2. מוודאים שהגודל בפועל של ה-desktop ב-host השתנה, וגוללים באותו דף.

   אם רק הקטנתם את החלון אצלכם, ייתכן שה-desktop הגדול פשוט מוצג מוקטן. מבחינים בין dynamic resolution לבין smart sizing, ובודקים מה ה-client שבו אתם משתמשים תומך. ראו: resolution של ה-desktop וקנה מידה של התצוגה.

3. מחזירים להגדרות המקוריות, חוזרים על אותה פעולה, ומשווים את העומס בשני הקצוות ואת התנועה על המסך.

   אם שיניתם בבת אחת גם ל-resolution נמוך וגם למסך אחד, ההשוואה היא גסה בלבד. אם המצב השתפר, החזירו כל שינוי בנפרד כדי להפריד בין ההשפעות.

אם המצב השתפר, יש רמז בתחום של עיבוד המסך והעברתו. ב-3840×2160 יש פי 4 pixels מאשר ב-1920×1080, אבל כמות התקשורת לא תמיד גדלה פי 4. היא תלויה בחלקים שהשתנו ובדחיסה, ושינוי ה-resolution משפיע גם על העיבוד בשני הקצוות. ראו: הקשר בין מספר ה-pixels לכמות התקשורת, בדיקת עיבוד המסך.

flowchart TB
    accTitle: מה אפשר ללמוד מהשוואה עם resolution נמוך יותר
    accDescr: הורדת ה-resolution בצד המרוחק עשויה לשנות גם את עומס עיבוד המסך וגם את עומס ההעברה, ולכן שיפור לבדו לא מצמצם את הסיבה לקו.
    A["הורדת ה-resolution בצד המרוחק"] --> S
    subgraph S["מה משתנה"]
    direction TB
    B["עיבוד המסך ב-host"] ~~~ C["כמות המידע שנשלחת"]
    C ~~~ D["עיבוד התצוגה אצלכם"]
    end

איור 11: שינוי ה-resolution הוא השוואה שמשפיעה לא רק על הקו, אלא גם על עיבוד המסך ב-host ואצלכם.

הצלבת העתקה והדפסה עם הסימפטום

עוצרים זמנית רק פעולות שמותר לכם לעצור, כמו העברות שאתם התחלתם. לא עוצרים גיבויים או תהליכי אבטחה של החברה, וגם לא jobs של משתמשים אחרים. לא מבטלים באופן גורף redirection של התקני אודיו או קלט שנחוצים לעבודה.

1. מתעדים את אותה פעולה ואת העומס לפני שמתחילים העתקה, סנכרון לענן או הדפסה, ובזמן שהם רצים.

   ב-RDP עובר לא רק המסך, אלא גם מידע של כוננים, מדפסות ועוד. Redirection, שמאפשר להשתמש ב-host בהתקנים שמחוברים למחשב שלכם, עשוי להגדיל את עומס התקשורת והעיבוד בזמן השימוש. ראו: ההשפעה של device redirection.

2. עוצרים זמנית את ההעברה הרלוונטית, במסגרת המותרת, ובודקים שוב את אותה פעולה.

   אם אפשר להמשיך את ההעברה ולהשוות, מתעדים גם את הסימפטום אחרי ההמשך. גם כשבודקים device redirection שלא נחוץ, משנים דבר אחד בכל פעם ודואגים שאפשר יהיה לחזור להגדרות המקוריות.

כך אפשר לקבוע אם תחילת ההעברה מתאימה לתחילת הבעיה, והעצירה הזמנית מתאימה להתאוששות. אם רואים התאמה, מצליבים את ההעברות שאינן של המסך ואת העומס על המשאבים המשותפים עם הרשומות של ה-admin.

flowchart TB
    accTitle: בודקים את הזמן שלפני הבעיה ואחריה על אותו ציר זמן
    accDescr: מתעדים את אותה פעולה ואת העומס לפני ההעברה, במהלכה ואחרי העצירה, ומשווים את הקשר בין הבעיה לבין הפעולה.
    A["פעולה ועומס לפני ההעברה"] --> B["פעולה ועומס במהלך ההעברה"]
    B --> C["פעולה ועומס אחרי העצירה"]
    C --> D["האם הבעיה וההתאוששות מתאימות"]

איור 12: בודקים איך האיטיות של אותה פעולה והעומס משתנים לפני ההעברה, במהלכה ואחרי העצירה.

למדוד איפה מחכים

מהמחשב שלכם בודקים את ה-round trip ברשת ואת חיבור ה-TCP, וב-host בודקים את ההמתנה ב-input queue ואת עדכוני המסך. כל מספר כזה מודד קטע מוגבל בלבד, ולכן קוראים את התוצאות מול הטבלה בפרק “מה תוצאות המדידה מכסות”.

בדיקת ICMP וחיבור TCP

מריצים את הבדיקה ממחשב ה-Windows שלכם. היא מיועדת רק לתצורה שבה מתחברים ישירות, ברשת ה-LAN הארגונית או ב-VPN מורשה, ל-RDP host שמשתמש ב-TCP 3389 הסטנדרטי. בתצורות שעוברות דרך RD Gateway או Azure Virtual Desktop, או שמשתמשות בפורט מותאם, החליטו יחד עם ה-admin מול מה בודקים. לא פותחים פורטים ולא משנים את ה-firewall.

1. מזינים host שמורשה לבדיקה, ומתעדים את התוצאות של תגובת ה-ICMP ושל חיבור ה-TCP.

   $target = Read-Host 'השם או כתובת ה-IP של ה-RDP host שמורשה לבדיקה'
   if ([string]::IsNullOrWhiteSpace($target)) {
       throw 'ציינו את ה-host שאליו מתחברים.'
   }
       
   # בודקים את זמן התגובה של ICMP כמה פעמים. כישלון לבדו לא מעיד ש-RDP לא נגיש.
   ping.exe -n 20 $target
       
   # בדיקה רק לתצורה של חיבור ישיר ל-TCP 3389 הסטנדרטי.
   Test-NetConnection -ComputerName $target -Port 3389 -InformationLevel Detailed
       
   

2. מצליבים את התוצאות משעות האיטיות ומזמנים רגילים עם זמני הסימפטום ועם נתיב החיבור בפועל.

   20 בדיקות ping הן תצפית קצרה. מתעדים תנודות בערכים ומקרים שבהם אין תגובה, אבל ייתכן גם ש-ICMP חסום. לא שוללים עצירות לסירוגין לפי ממוצע בלבד, ומשתמשים במידע על החיבור וברשומות התקשורת של ה-admin. ראו: מה ping מודד.

TcpTestSucceeded: True אומר שחיבור TCP לפורט שצוין הצליח. הבדיקה לא מודדת רוחב פס, UDP, פעולות אחרי האימות או את החלקות של המסך. ל-Test-NetConnection אין switch בשם -UDP שבודק UDP. ראו: התחביר והתוצאות של Test-NetConnection.

כשמסיקים מסקנות, לוקחים בחשבון את ההבדלים בנתיב ובשירות. עם RD Gateway וכדומה, הנתיב של ICMP או של חיבור TCP ישיר ל-host עשוי להיות שונה מהנתיב של ה-RDP בפועל. ב-Azure Virtual Desktop אפשר לקבל RTT והערכת רוחב פס לכל חיבור, אבל יכולת האבחון הזו מיועדת לשירות הזה. לא שוללים עצירות קצרות לפי ממוצע בלבד. ראו: לוגים של איכות החיבור ב-Azure Virtual Desktop.

flowchart TB
    accTitle: הנתיב שנבדק לעומת נתיב ה-RDP בפועל
    accDescr: בתצורות עם RD Gateway וכדומה, הנתיב של ICMP או של חיבור TCP ישיר מהמחשב שלכם ל-host עשוי להיות שונה מנתיב ה-RDP בפועל.
    A["המחשב שלכם"] -->|"ICMP ו-TCP ישיר"| C["RDP host"]
    A -->|"RDP בפועל"| B["RD Gateway וכדומה"]
    B --> C

איור 13: הנתיב של ICMP או של חיבור TCP ישיר ל-host עשוי להיות שונה מהנתיב של ה-RDP בפועל.

מדידת ההמתנה ב-input queue

User Input Delay מודד את ההמתנה ב-host מהרגע שה-input נכנס ל-queue ועד שה-process מוציא אותו. זה לא הזמן הכולל מלחיצה על מקש ועד שהתו נראה. ראו: ההגדרה של User Input Delay.

בודקים מתוך ה-session המרוחק ב-host. לפי Microsoft, התמיכה היא ב-Windows 10 גרסה 1809 ומעלה וב-Windows Server 2019 ומעלה. בגרסאות האלה אין צורך להוסיף ערך ב-Registry כדי להפעיל את זה. בודקים את שם התצוגה, ההרשאות ואם ה-counter קיים, ואם הוא לא זמין, מתעדים את זה ומתייעצים עם ה-admin. ראו: תנאי תמיכה והגדרות.

1. ב-PowerShell באותו session, רושמים את השעה ואת ה-session ID.

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

   כדי לשאול על sessions של משתמשים אחרים ייתכן שיידרשו הרשאות נוספות. שם ה-instance הסטנדרטי של ה-process הרלוונטי הוא SessionID:ProcessID <Process Image>. הקפידו לא לערבב, על סמך ה-session ID בלבד, ערכים של משתמשים אחרים או של processes עם אותו שם. ראו: ההרשאות של query session, זיהוי ה-instance.

2. ב-perfmon.exe מוסיפים את User Input Delay per Process או את User Input Delay per Session, לפי מה שזמין.

   בוחרים את ה-process או ה-session הרלוונטיים, ובהתחלה צופים במרווח ברירת המחדל של שנייה אחת. הבחינו בין ה-instance המצטבר, שמאחד כמה sessions, לבין הערכים של session בודד.

3. משחזרים את הפעולה שבה ה-input איטי, ומשווים את ההמתנה ב-queue לזמני הסימפטום.

   עבור יעד מדידה בודד, הערך הוא זמן ההמתנה המקסימלי בתוך מרווח המדידה. גם כשהערך נמוך, עדיין יכולים להיות עיכובים בעיבוד אחרי שהאפליקציה הוציאה את ה-input, או עד שהתוצאה חוזרת אליכם.

כך אפשר לבדוק אם יש המתנה ב-input queue ב-host. זה מדד נפרד מהזמן שאתם מרגישים, שכולל את ה-round trip ברשת ואת ההצגה אצלכם. ראו: המשמעות של הערך המקסימלי ושל מרווח המדידה.

flowchart TB
    accTitle: הקטע ש-User Input Delay מודד
    accDescr: קטע המדידה הוא מה-input queue ב-host ועד שהאפליקציה מוציאה את ה-input, והתקשורת והצגת המסך שלפניו ואחריו לא נכללות.
    A["ה-input מגיע מהמחשב שלכם"] --> B["נכנס ל-input queue ב-host"]
    B -->|"זה הקטע הנמדד"| C["האפליקציה מוציאה את ה-input"]
    C --> D["עיבוד האפליקציה והעברת המסך"]
    D --> E["מוצג אצלכם"]

איור 14: מה שנמדד הוא ההמתנה ב-input queue ב-host. זה לא הזמן הכולל עד שהתוצאה נראית אצלכם.

עדכוני מסך וסיבות לדילוג על frames

מכינים פעולה שיוצרת עדכוני מסך רצופים, כמו scroll. צריך לבדוק אם ה-counters של RemoteFX Graphics זמינים ואיפה מודדים אותם, לפי מערכת ההפעלה, תצורת ה-host וההרשאות. כאן רק קוראים counters שכבר זמינים. זה לא תהליך להתקנה או להפעלה של יכולות RemoteFX הישנות. ראו: תנאי השימוש ב-Graphics counters.

1. בודקים את שם ה-session הרלוונטי עם query session או qwinsta, ובוחרים את ה-instance המתאים של ה-counter.

2. בזמן פעולה שיש בה עדכוני מסך, משווים בין Input Frames/Second ל-Output Frames/Second.

   אם יש פחות output מ-input, חלק מה-frames מדולגים בדרך. בודקים את הערכים של Frames Skipped/Second לפי סוג המחסור במשאבים: ב-host, ברשת או ב-client.

3. מצליבים את סיבות הדילוג עם העומס בשני הקצוות וברשת, ובודקים גם את Average Encoding Time.

   אם זמן ה-encoding ארוך, חוקרים את הדחיסה ב-host. אם מספר ה-frames נמוך כבר בצד ה-input, ייתכן גם שהאפליקציה פשוט לא מעדכנת את המסך לעתים קרובות. מספר frames נמוך במסך סטטי אינו חריג כשלעצמו.

לפי ה-input וה-output בזמן עדכוני מסך, סיבות הדילוג וזמן ה-encoding, אפשר לצמצם את המקום לחקירה. החלוקה של ה-counters היא רמז, ומסיקים מסקנות רק יחד עם העומס בפועל ותצורת החיבור. ראו: איך קוראים את מספר ה-frames ואת זמן ה-encoding.

flowchart TB
    accTitle: מצמצמים את מקום החקירה לפי ה-frames שדולגו
    accDescr: בזמן פעולה עם עדכוני מסך משווים את מספר ה-frames ב-input וב-output, ובעזרת ה-counters של סיבות הדילוג מצליבים עם העומס בעיבוד, בתקשורת ובתצוגה.
    A["משווים input ו-output בזמן scroll"] --> B["פחות output: בודקים דילוג"]
    B --> C["בודקים counters לפי סיבה"]
    C --> D["מצליבים עם עומס ב-host, ברשת ואצלכם"]

איור 15: משווים input ו-output בזמן scroll, ומצליבים את סיבות הדילוג עם העומס ב-host, בקו ואצלכם.

לא מכלילים את התרשים העקרוני של העברת המסך או תיעוד ישן על כל התצורות. יש תצורות שבהן וידאו ואודיו מועברים במנגנון נפרד. התיעוד של Graphics counters כולל גם הסברים על תצורות ישנות, ולכן לא הופכים את המספרים שמופיעים בו למפרט כללי כמו “כל RDP מוגבל ל-30fps”. לפני שמשתמשים ביכולות ובמספרים, בודקים על מה הם חלים. ראו: העברת המסך ו-workloads, התיעוד של Graphics counters.

מה תוצאות המדידה מכסות

ערך נמוך ופעולה שמרגישה נוח הם לא אותו דבר. את הטווח של כל מדד אפשר לבדוק בתיעוד של Microsoft שמופיע בתהליכים.

הגדרות רשת ו-GPU

את הגדרות ה-UDP וה-GPU בוחרים לפי מה שההשוואות והמדידות הראו. אם התקשורת חשודה, בודקים קודם את שיטת החיבור ואת הנתיב, ואם עיבוד המסך חשוד, בודקים קודם באילו שלבים משתמשים ב-GPU.

בדיקת TCP, UDP ונתיב החיבור

אם ההשוואות והמדידות מצביעות על התקשורת, בודקים עם ה-admin את ה-client שבשימוש, את הנתיב ואת ה-policies שמוחלות. גם כשצריך לשנות הגדרות, עושים זאת רק במסגרת שאושרה, ומתעדים את הערכים שלפני השינוי ואת דרך השחזור. לא מבטלים את ה-firewall או את האימות, ולא חושפים את פורט ה-RDP ישירות לאינטרנט.

1. בודקים בעזרת מידע החיבור, לוגי האבחון של המוצר ורשומות התקשורת של ה-admin אם בפועל משמש TCP או UDP, ומה הנתיב.

   RDP משתמש ב-TCP או ב-UDP לפי התצורה ותנאי הרשת. ב-“Select RDP transport protocols” אפשר לבחור בין הגדרה שמשתמשת ב-UDP או ב-TCP לבין הגדרה של TCP בלבד. מכיוון שקיימת גם התנהגות שבה משתמשים ב-TCP אם חיבור UDP לא נוצר, הצלחת החיבור לבדה לא מראה באיזו שיטה הוא עובד. ראו: בחירת RDP transport ו-fallback.

2. מצליבים את זמני הסימפטום עם הנתיב והשיטה, ומשווים רק את ההגדרות הנחוצות, אחת בכל פעם.

   לא משנים באופן גורף מתוך הנחה ש”אם מכבים UDP זה יהיה מהיר יותר”. משווים כשתנאי ה-VPN או ה-gateway, הפעולה ותנאי התצוגה זהים, ומחזירים שינויים שלא נחוצים.

אחרי שיודעים מה השיטה ומה הנתיב, אפשר לתעד את הקשר בין השינוי לסימפטום. מעבר ל-TCP בלבד לא תמיד מאיץ.

flowchart TB
    accTitle: בודקים את שיטת החיבור ואז משווים הגדרות רשת
    accDescr: מבחינים בין חיבור ישיר רגיל לחיבור דרך gateway או שירות, בודקים את הנתיב והשיטה בפועל, ורק אז מבצעים השוואה מורשית.
    A["ה-client ותצורת החיבור"] --> B["בודקים נתיב ו-TCP/UDP בפועל"]
    B --> C["מצליבים עם זמני הסימפטום"]
    C --> D["משווים רק הגדרות נחוצות, אחת בכל פעם"]

איור 16: בודקים את שיטת החיבור ואת הנתיב שבשימוש, מצליבים עם הסימפטום, ורק אז משווים את ההגדרות הנחוצות.

RDP Shortpath הוא מנגנון של Azure Virtual Desktop. הוא מקים נתיב UDP של השירות, ולפי התצורה משתמש בנתיב ישיר או ב-relay. אם לא מצליחים להקים אותו, החיבור חוזר לחיבור מבוסס TCP. אי אפשר להשתמש באותה טבלת הגדרות כמו כשמתחברים ישירות עם mstsc למחשב בארגון. ראו: הנתיבים של RDP Shortpath וה-fallback.

flowchart TB
    accTitle: הנתיבים של RDP Shortpath וה-fallback
    accDescr: RDP Shortpath של Azure Virtual Desktop מנסה להקים נתיב UDP. אם זה מצליח, הוא משתמש בנתיב ישיר או ב-relay לפי התצורה, ואם לא, חוזר לחיבור מבוסס TCP.
    A["RDP Shortpath"] --> B{"נתיב UDP"}
    B -->|"הוקם"| C["ישיר או relay"]
    B -->|"לא הוקם"| D["חזרה לחיבור מבוסס TCP"]

איור 17: אם RDP Shortpath לא מצליח להקים נתיב UDP, הוא חוזר לחיבור מבוסס TCP.

בדיקת השימוש ב-GPU בעיבוד המסך

בודקים את זה אם ההשוואות והמדידות מצביעות על עיבוד המסך. בודקים את תוצאות המדידה של עיבוד המסך, ואת מערכות ההפעלה, הדרייברים, ה-policies וה-clients הנתמכים. לא משנים הגדרות רק כי יש GPU במחשב. קודם מקבלים אישור מה-admin ומתכוננים להחזרה למצב המקורי.

1. מפרידים בין ה-rendering של האפליקציה ב-host, ה-encoding של RDP וה-decoding אצלכם, ובוחרים את השלב החשוד.

   גם כשיש GPU, לא כל השלבים בהכרח משתמשים בו. גם בתיעוד התצורה של Microsoft ל-Azure Virtual Desktop, ה-rendering של ה-session המרוחק וה-hardware encoding של ה-frames מוגדרים ונבדקים בנפרד. ראו: הגדרה ואימות של GPU ל-rendering ול-encoding.

2. בודקים את השימוש בפועל לפי התהליך של המוצר הרלוונטי, ומודדים את אותה פעולה לפני השינוי הנחוץ ואחריו.

   אם זמן הדחיסה ארוך, בודקים את השימוש ב-GPU ל-encoding. אם האפליקציה מחכה ב-input queue, שינוי בהגדרות ה-encoding מכוון למקום הלא נכון. גם האיזון בין איכות תמונה, כמות תקשורת ועומס עיבוד שונה כשהמטרה היא טקסט קריא לעומת וידאו חלק. ראו: ההבדלים לפי workload.

כך אפשר לתעד לא רק אם יש GPU, אלא אם הוא משמש בשלב הבעייתי, ואיך העומס והתגובה של אותה פעולה השתנו. שינוי שלא הביא שיפור מחזירים למצב המקורי, בתיאום עם ה-admin.

flowchart TB
    accTitle: בודקים את השימוש ב-GPU בכל שלב
    accDescr: מפרידים בין ה-rendering של האפליקציה ב-host, ה-encoding של RDP וה-decoding אצלכם, ומכיוון שגם כשיש GPU לא כל השלבים בהכרח משתמשים בו, בודקים את השימוש בשלב החשוד.
    A["Rendering של האפליקציה ב-host"] --> B["Encoding של RDP"]
    B --> C["Decoding אצלכם"]
    C -.- D["בודקים שימוש ב-GPU בכל שלב"]

איור 18: גם כשיש GPU, לא בהכרח rendering, encoding ו-decoding כולם משתמשים בו.

אימות חוזר והעברת החקירה

שיפור מאשרים כשאחרי השינוי אפשר לבצע את אותה פעולה בלי בעיות, וגם איכות התמונה, ההתקנים והיכולות העסקיות הנחוצים נשמרים. הצליבו גם עם התוצאה אחרי ההחזרה לתנאים המקוריים. אם היה רק שיפור רגעי, לא קובעים את הסיבה, ומתעדים גם שעות עומס ופעולות שרצו במקביל.

flowchart TB
    accTitle: הסדר לאימות שיפור
    accDescr: אחרי השינוי בודקים שאותה פעולה מתבצעת בלי בעיות וגם שאיכות התמונה, ההתקנים והיכולות העסקיות הנחוצים נשמרים, מצליבים עם התוצאה אחרי ההחזרה לתנאים המקוריים, ולא קובעים את הסיבה לפי שיפור רגעי בלבד.
    A["מנסים את אותה פעולה אחרי השינוי"] --> B["בודקים איכות, התקנים ויכולות עסקיות"]
    B --> C["מצליבים עם התוצאה אחרי ההחזרה"]
    C -.- D["שיפור רגעי לא מכריע"]

איור 19: בנוסף לתוצאה של אותה פעולה, מצליבים גם את היכולות הנחוצות ואת התוצאה אחרי ההחזרה.

העברת החקירה כשהבעיה לא נפתרה

גם כשאין שיפור, כשהבעיה לא משתחזרת או כשה-counters לא זמינים, זו תוצאה שימושית. מפרידים בין ההשוואות שבוצעו לבין הבדיקות שלא התאפשרו, ומעבירים ל-admins ולמפתחים בעזרת התבנית הבאה. הסירו מהלוגים המשותפים מידע עסקי שלא נחוץ לחקירה, כמו שמות משתמשים ושמות hosts.

השעה שבה הופיע הסימפטום ו-time zone:
מערכת ההפעלה של ה-host, ה-client והגרסה:
חיבור ישיר / VPN / RD Gateway / Azure Virtual Desktop וכו':
הפעולה והאפליקציה האיטיות, התגובה של אפליקציה אחרת באותו session:
ה-resolution ומספר המסכים בצד המרוחק:
העתקה, הדפסה וכו' שרצו באותו זמן:
התנאי היחיד ששונה, והתוצאה אחרי ההחזרה:
עומס ו-counters שנצפו ב-host ואצלכם:

הוסיפו גם אם הצלחתם לבדוק מה משמש בפועל, TCP או UDP, אילו פריטים לא נבדקו בגלל חוסר הרשאות או סיבות אחרות, ואילו הגדרות מקובלות מבחינת העבודה. תיאור כמו “ב-Notepad מקלידים כרגיל, אבל scroll בתמונות נתקע” עוזר למי שממשיך את החקירה לבדוק באותם תנאים יותר מאשר “הקו איטי”.

המשתמשים מתעדים את הפעולה שמשחזרת את הבעיה ואת תוצאות ההשוואה, וה-admins מצליבים את הרשומות של נתיב החיבור, ה-host המשותף וה-sessions. זה שההמתנה מתרחשת דרך RDP לא אומר בהכרח שגם מה שגורם להמתנה הוא RDP. ראו: חלוקת התפקידים בין ה-host ל-backend.

מפתחי האפליקציה מתעדים בנפרד את קבלת אירוע ה-input, את ההתחלה והסיום של עיבוד ה-DB והקבצים, ואת העדכון ב-UI. שוקלים גם תכנון שלא משאיר עבודה כבדה על ה-UI thread. עם זאת, לוג שמראה שהעיבוד ב-host הסתיים לא מתעד את הרגע שבו ההצגה אצלכם הסתיימה. ראו: הפרדת עיבוד כדי לשמור על תגובתיות ה-UI.

מאמרים קשורים

• איך להבין את בידוד ה-sessions ב-Windows
• בידוד בטוח של דיסק ב-100% ב-Windows
• למה “נותרה שנייה אחת” לא נגמרת?

מקורות

אלה מקורות ראשוניים מ-Microsoft Learn. התוכן שמוזכר כאן נבדק ב-17 בספטמבר 2026. קראו אותם תוך הבחנה בתנאי התחולה של כל מוצר, וזכרו שאלה לא מדידות שבוצעו בפועל במסגרת המאמר הזה.

• Microsoft Learn, Analyze connection quality in Azure Virtual Desktop. ההבחנה בין RTT לבין ה-delay מלכידת המסך ב-host ועד ההצגה אצלכם. יכולת האבחון עצמה מיועדת ל-Azure Virtual Desktop.
• Microsoft Learn, Remote Desktop Protocol bandwidth requirements. הקשר בין תוכן המסך, ה-resolution, עדכוני frames, דחיסה ו-caching לבין כמות התקשורת.
• Microsoft Learn, Diagnose graphics performance issues in Remote Desktop. איך בודקים input ו-output של המסך, סיבות לדילוג על frames וזמן encoding. מכיוון שהתיעוד כולל הסברים על תצורות ישנות, לא מכלילים את הגבולות המספריים על כל RDP.
• Microsoft Learn, Performance Tuning Remote Desktop Session Hosts. העומס על host משותף, התקשורת מה-host ל-backend, וההשפעה של device redirection.
• Microsoft Learn, Threading model. ה-UI thread וה-Dispatcher ב-WPF, והפרדת עיבוד כדי לשמור על תגובתיות.
• Microsoft Learn, mstsc. הגדרת הרוחב והגובה של Remote Desktop ושימוש בכמה מסכים.
• Microsoft Learn, Supported RDP properties. ההבחנה בין resolution של ה-desktop, dynamic resolution ו-smart sizing. בודקים את ה-clients הנתמכים ואת תנאי התחולה של כל מוצר.
• 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, מערכות ההפעלה הנתמכות, ה-instances, ומשמעות הערך המקסימלי.
• Microsoft Learn, query session. מידע על sessions, וההרשאות שנדרשות כדי לשאול על sessions אחרים.
• Microsoft Learn, ADMX_TerminalServer Policy CSP. הבחירה בין TCP ל-UDP ש-RDP משתמש בהם, וה-fallback.
• Microsoft Learn, RDP Shortpath. נתיב ה-UDP של Azure Virtual Desktop, וההתנהגות כשאי אפשר להקים אותו.
• Microsoft Learn, Enable GPU acceleration for Azure Virtual Desktop. הגדרה ואימות של GPU, בנפרד ל-rendering ול-frame encoding.

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

אלה דפי נושא הקרובים לנושא הזה. מהמאמר אפשר להמשיך לשירותים קשורים ולמאמרים אחרים.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בהתייעצויות בנושא המאמר.

בדיקת מהירות מראה כמה מאות Mbps. למה ה-input ב-RDP איטי?

המהירות שבה עובר נפח גדול של data והזמן עד שפעולה מקבלת תגובה הם שני דברים שונים. מעורבים כאן שליחת ה-input, העיבוד של האפליקציה ב-host, דחיסת המסך, ההעברה וההצגה במחשב שלכם. בנוסף, הנתיב ברשת לשרת של בדיקת המהירות שונה מהנתיב ל-RDP host.

הקלדה עובדת כרגיל ורק ה-scroll מקרטע. זו בעיה בקו?

אי אפשר לצמצם את זה לקו בלבד. כשעדכוני המסך מתרבים, ייתכן שה-rendering והדחיסה ב-host, התקשורת, או ה-decoding וההצגה במחשב שלכם לא עומדים בקצב. משנים את ה-resolution או את מספר המסכים בצד המרוחק, אחד בכל פעם, ומשווים, ואם צריך בודקים counters שקשורים ל-rendering.

אם ה-ping מהיר, התקשורת של RDP תקינה?

זה לבד לא מספיק כדי לקבוע. ping מודד תגובה ל-ICMP, ולא את העברת המסך של RDP או את העיבוד של האפליקציה. בתצורות שמשתמשות ב-RD Gateway וכדומה, גם הנתיב עשוי להיות שונה. וגם כשאין תגובה, הפרידו בין ICMP חסום לבין מצב ש-RDP עצמו לא מגיע ליעד.

האם User Input Delay הוא הזמן מלחיצה על מקש ועד שהתו מופיע?

לא. זה counter שמודד את זמן ההמתנה ב-host מהרגע שה-input נכנס ל-queue ועד שה-process מוציא אותו. זה לא ה-delay שאתם מרגישים, שכולל את ה-round trip ברשת, את עיבוד האפליקציה אחרי שה-input הוצא, ואת הדחיסה, ה-decoding וההצגה של המסך.

כש-RDP איטי, צריך לבטל UDP?

לא ממליצים על זה באופן גורף. קודם בודקים את שיטת החיבור והנתיב בפועל ואת ה-policies שמוחלות. ייתכן ש-UDP לא זמין והחיבור כבר עשה fallback ל-TCP, ומעבר ל-TCP בלבד לא תמיד מאיץ. משווים בתנאים זהים באישור ה-admin, ומחזירים שינויים שלא נחוצים.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

נציג KomuraSoft LLC

מתמקד בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, וחזק במיוחד בפרויקטים שבהם נותרו נכסים קיימים ובחקירת תקלות שגורמן קשה לזיהוי.