ทำไม RDP ถึงหน่วงทั้งที่อินเทอร์เน็ตเร็ว ── แยกตรวจสอบอินพุต การเรนเดอร์ และการสื่อสาร

ทดสอบความเร็วได้หลายร้อย Mbps แต่บนเดสก์ท็อประยะไกล ตัวอักษรกลับปรากฏช้าไปเล็กน้อย เลื่อนหน้าที่มีรูปภาพมากแล้วหน้าจอสะดุด กดค้นหาในแอปธุรกิจแล้วค้างไปหลายวินาทีเฉพาะตอนนั้น สภาพ “อินเทอร์เน็ตเร็วแต่ RDP หน่วง” แบบนี้ ควรเริ่มตรวจสอบจากตรงไหน

การตอบสนองต่อการกระทำใน RDP ไม่ได้ถูกกำหนดด้วยความเร็วในการรับส่งข้อมูลของเครือข่ายเพียงอย่างเดียว แม้ผลทดสอบความเร็วจะออกมาเร็ว ก็อาจเกิดการรอที่จุดใดจุดหนึ่ง ได้แก่ การไป-กลับของการสื่อสาร การรออินพุตของแอปบนเครื่องปลายทาง การเอนโค้ดหน้าจอ หรือการดีโค้ดและการแสดงผลบนเครื่องฝั่งผู้ใช้ ก่อนอื่น โปรดแยกว่า “การกระทำใดที่ช้า” แล้วเปรียบเทียบการกระทำเดียวกันโดยเปลี่ยนเงื่อนไขทีละอย่าง ให้จำกัดวงจุดที่ต้องตรวจสอบด้วยการเปรียบเทียบและการวัด แล้วเลือกการตั้งค่า UDP หรือ GPU ให้สอดคล้องกับผลนั้น ดูเพิ่มเติม: ช่วงที่วัดคุณภาพการเชื่อมต่อ, ปัจจัยด้านประสิทธิภาพของโฮสต์เซสชัน

อย่างไรก็ตาม ในขั้นที่จำกัดวงจุดตรวจสอบได้แล้ว สาเหตุที่แท้จริงก็ยังไม่ได้รับการยืนยัน แม้ลดความละเอียดแล้วอาการดีขึ้น ก็ไม่สรุปว่า “เครือข่ายคือสาเหตุ” เพราะไม่ได้เปลี่ยนแค่การสื่อสาร แต่การประมวลผลหน้าจอที่ปลายทั้งสองฝั่งก็เปลี่ยนด้วย ให้บันทึกผลโดยแยกช่วงที่วัดกับช่วงที่ไม่ได้วัดออกจากกัน

บทความนี้แยกปัญหาอินพุต การเลื่อนหน้าจอ และการตอบสนองของแอปหลังเชื่อมต่อแล้ว แม้อาการจะคล้ายกัน สาเหตุก็ไม่จำเป็นต้องมีเพียงอย่างเดียว กรณี “กว่าหน้าจอล็อกอินจะขึ้นใช้เวลานาน” หรือ “ค้างเฉพาะตอนยืนยันตัวตน” จะถือเป็นปัญหาอีกเรื่องหนึ่งที่ต้องตรวจสอบจากบันทึกการสร้างการเชื่อมต่อหรือการยืนยันตัวตน

กลุ่มเป้าหมายหลักคือผู้ใช้และผู้ดูแลระบบที่เชื่อมต่อจาก “การเชื่อมต่อเดสก์ท็อประยะไกล” (mstsc) ของ Windows ไปยัง Windows 11 หรือ Windows Server ตัวอย่างคำสั่งใช้กับ 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 รับส่ง

ความเร็วในการรับส่งข้อมูลของเครือข่ายบอกว่าใน 1 วินาทีขนข้อมูลได้มากเพียงใด “500Mbps” ในผลทดสอบความเร็วเป็นตัวเลขเกี่ยวกับปริมาณนี้ ไม่ใช่ตัวเลขที่บอกเวลาตั้งแต่ทำการกระทำจนได้รับการตอบกลับ ดูเพิ่มเติม: ข้อกำหนดแบนด์วิดท์ของ RDP

flowchart TB
    accTitle: ตัวเลขจากการทดสอบความเร็วบอกอะไร
    accDescr: 500Mbps จากการทดสอบความเร็วเป็นตัวเลขของปริมาณข้อมูลที่ขนได้ใน 1 วินาที และเป็นคนละตัวเลขกับเวลาตั้งแต่ทำการกระทำจนได้รับการตอบกลับ
    A["ทดสอบความเร็ว: 500Mbps"] --> B["ข้อมูลที่ขนได้ใน 1 วินาที"]
    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 ในเซสชันเดียวกันยังพิมพ์ได้ตามปกติ ให้ตรวจสอบว่าแอปนั้นกำลังรออะไร แอปบนเครื่องปลายทางอาจส่งคำขอค้นหาต่อไปยัง DB อีกตัว หรืออ่านไฟล์จากโฟลเดอร์ที่ใช้ร่วมกัน แล้วรอการตอบกลับนั้นอยู่ ซึ่งเป็นคนละเส้นทางกับการสื่อสาร RDP ที่เชื่อมฝั่งผู้ใช้กับเครื่องปลายทาง ดูเพิ่มเติม: การสื่อสารจากเครื่องปลายทางไปยังแบ็กเอนด์

flowchart TB
    accTitle: เลย RDP ออกไปก็ยังมีคู่สื่อสาร
    accDescr: แสดงกรณีที่แอปบนเครื่องปลายทางรอการตอบกลับจากเซิร์ฟเวอร์ธุรกิจ ซึ่งแยกจากการสื่อสารที่เชื่อมเครื่องฝั่งผู้ใช้กับเครื่องปลายทาง
    A["เครื่องฝั่งผู้ใช้"] -->|"RDP"| B["แอปธุรกิจบนปลายทาง"]
    B -->|"คำขอค้นหาและไฟล์"| C["DB และโฟลเดอร์แชร์"]
    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 หรือแอปอื่นในเซสชันเดียวกันยังตอบสนองหรือไม่ หากแอปอื่นทำงานได้ ให้ตรวจสอบการประมวลผลของแอปเป้าหมาย ดิสก์ และคำขอไปยัง DB หรือโฟลเดอร์ที่ใช้ร่วมกันก่อน การที่กำลังใช้งานผ่าน RDP กับการที่การสื่อสาร RDP เป็นสาเหตุของการรอเป็นคนละเรื่องกัน ดูเพิ่มเติม: ปัจจัยด้านประสิทธิภาพของแอปและแบ็กเอนด์

ช้ากันทุกคนเฉพาะช่วงที่ผู้ใช้เพิ่มขึ้น

หากช้าลงกับผู้ใช้หลายคนในช่วงเวลาเดียวกัน ให้สอบถามผู้ดูแลระบบถึงสถานการณ์ของเซสชันอื่น เทียบโหลดของ CPU หน่วยความจำ และที่เก็บข้อมูลของโฮสต์ที่ใช้ร่วมกัน รวมถึงเครือข่ายที่ใช้ร่วมกัน ให้ตรงกับเวลาที่เกิดอาการ ไม่เข้าถึงบันทึกหรืองานประมวลผลของผู้ใช้คนอื่นโดยไม่ได้รับอนุญาต และไม่หยุดจ็อบของผู้อื่น ดูเพิ่มเติม: ทรัพยากรของโฮสต์ที่ใช้ร่วมกันกับจำนวนผู้ใช้

ช้าลงระหว่างคัดลอกหรือสั่งพิมพ์

หากเวลาที่ตนเองเริ่มคัดลอกหรือสั่งพิมพ์ตรงกับช่วงที่เกิดปัญหา ให้หยุดชั่วคราวเฉพาะการรับส่งที่ได้รับอนุญาตให้หยุดแล้วเปรียบเทียบ บันทึกว่าหลังหยุดแล้วกลับมาปกติหรือไม่ และเมื่อทำต่อแล้วช้าลงหรือไม่ แล้วตรวจสอบการแย่งกันกับการรับส่งที่ไม่ใช่หน้าจอหรือการเปลี่ยนเส้นทางอุปกรณ์ ไม่เปรียบเทียบด้วยการปิดใช้งานอุปกรณ์ที่จำเป็นต่องานทั้งหมดในคราวเดียว ดูเพิ่มเติม: ผลของการเปลี่ยนเส้นทางอุปกรณ์

เปรียบเทียบเงื่อนไขทีละอย่าง

ไม่จำเป็นต้องเปลี่ยนการตั้งค่าทุกอย่างตามลำดับ ให้สร้างเกณฑ์สำหรับเปรียบเทียบก่อน แล้วเลือกเฉพาะการตรวจสอบที่ตรงกับอาการ ก่อนเปลี่ยนการตั้งค่าหรือเชื่อมต่อใหม่ โปรดบันทึกไฟล์งานที่ทำอยู่ และจดค่าเดิมกับวิธีเปลี่ยนกลับไว้ หากไม่มีสิทธิ์หรือฟังก์ชันที่จำเป็น อย่าฝืนเปิดใช้งาน ให้ส่งต่อให้ผู้ดูแลระบบ

การใช้งานบนเครื่องโดยตรงกับการใช้งานผ่าน RDP ไม่จำเป็นต้องอยู่ในเงื่อนไขเดียวกัน การที่หน้าจอจริงของเครื่องปลายทางเร็วเป็นข้อมูลอ้างอิงได้ แต่เงื่อนไขของเซสชันหรือการเรนเดอร์อาจเปลี่ยนไป ให้จัดผู้ใช้ ข้อมูล และสถานะของแอปให้เหมือนกัน และอย่าจำกัดสาเหตุไว้ที่เครือข่ายเพียงเพราะ “หน้าจอจริงเร็ว”

เปรียบเทียบการกระทำเดียวกัน

เตรียมผู้ใช้ ข้อมูล และการกระทำเดียวกัน บนโฮสต์ที่ใช้ร่วมกัน ให้ตรวจสอบเซสชันของตนเอง และไม่หยุดแอปหรืองานของผู้ใช้คนอื่น การใช้เครื่องอื่นหรือเส้นทางอื่นก็จำกัดอยู่ในขอบเขตที่ผู้ดูแลระบบอนุญาตเช่นกัน

1. ทำให้การกระทำที่ช้าเกิดซ้ำด้วยการตั้งค่าเดิม แล้วจดเวลาและอาการไว้

   พิมพ์ตัวอักษรในปริมาณใกล้เคียงกันลงใน Notepad ในเซสชันรีโมตเดียวกับแอปที่มีปัญหา เพื่อแยกว่าเป็นเพียงแอปเดียวหรือทั้งเซสชัน

2. ตรวจสอบโหลดของเครื่องปลายทางและฝั่งผู้ใช้ในช่วงเวลาเดียวกัน

   ในตัวจัดการงาน ให้ดู CPU หน่วยความจำ และดิสก์ของแอปเป้าหมายบนเครื่องปลายทาง และดูโหลดของไคลเอนต์ RDP บนฝั่งผู้ใช้ ตรวจสอบโปรเซสเป้าหมาย ไม่ใช่ดูเฉพาะค่า CPU โดยรวม ดูเพิ่มเติม: สิ่งที่ต้องตรวจโหลด

3. เปลี่ยนเพียงเงื่อนไขเดียว ระหว่างเครื่องอื่น เส้นทางอื่นที่ได้รับอนุญาต หรือเงื่อนไขการแสดงผล แล้วทำการกระทำเดิมซ้ำ

   ในการเปรียบเทียบที่สถานะของเครื่องปลายทางหรือแอปเปลี่ยนไปพร้อมกัน ให้จดความต่างนั้นไว้ด้วย ไม่ถือว่าผลที่เกิดจากหลายเงื่อนไขเปลี่ยนเป็นผลของเงื่อนไขเดียว

4. เปลี่ยนกลับเป็นเงื่อนไขเดิม แล้วตรวจสอบการกระทำเดิมอีกครั้ง

   หากเปลี่ยนกลับแล้วยังเร็วอยู่ ก็อาจเป็นเพราะโหลดเปลี่ยนไปชั่วคราว เป็นต้น อย่าด่วนสรุปว่าการเปลี่ยนได้ผล ให้จดเงื่อนไขที่ทำให้อาการเกิดซ้ำ

เมื่อได้ผลครบทั้งสถานะเดิม หลังเปลี่ยน และหลังเปลี่ยนกลับ ก็เปรียบเทียบได้ว่าเงื่อนไขใดสอดคล้องกับอาการใด เงื่อนไขที่ทำให้ดีขึ้นเป็นเบาะแสของการตรวจสอบ และโดยลำพังไม่ใช่ข้อพิสูจน์สาเหตุที่แท้จริง

flowchart TB
    accTitle: จำกัดเงื่อนไขที่เปลี่ยนในแต่ละครั้ง
    accDescr: ลำดับการกำหนดการกระทำที่เกิดซ้ำได้ในสถานะเดิม เปลี่ยนเพียงเงื่อนไขเดียวแล้วเปรียบเทียบ และตรวจผลหลังเปลี่ยนกลับด้วย
    A["การกระทำเดิมด้วยค่าเดิม"] --> B["เปลี่ยนเพียงเงื่อนไขเดียว"]
    B --> C["ทำการกระทำเดิมซ้ำ"]
    C --> D["เปลี่ยนกลับแล้วตรวจซ้ำ"]
    D --> E["จดเงื่อนไขที่ดีขึ้น"]

ภาพ 10: ทำการกระทำเดิมซ้ำในสถานะเดิม หลังเปลี่ยน และหลังเปลี่ยนกลับ แล้วจดเงื่อนไขที่เปลี่ยนไป

เปรียบเทียบความละเอียดฝั่งรีโมต

ใช้เปรียบเทียบเมื่อการอัปเดตหน้าจอหนัก เช่นตอนเลื่อนหน้าจอ จดความละเอียดและจำนวนจอภาพก่อนเปลี่ยน บันทึกไฟล์งานที่ทำอยู่ แล้วจึงเชื่อมต่อใหม่ ไม่ใช้การตั้งค่าที่ทำให้หน้าจอที่จำเป็นต่องานหรือความอ่านง่ายของตัวอักษรแย่ลงต่อไปเป็นประจำ

1. เปลี่ยนเพียงอย่างใดอย่างหนึ่ง ระหว่างจำนวนจอภาพหรือความละเอียด

   ใน mstsc สามารถเปรียบเทียบได้ด้วยการตั้งค่า “การแสดงผล” ก่อนเชื่อมต่อ หรือการระบุความกว้างและความสูง ดูเพิ่มเติม: การระบุหน้าจอของ 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 ฝั่งผู้ใช้ เป้าหมายมีเฉพาะโครงสร้างที่เชื่อมต่อตรงจาก LAN ในองค์กรหรือ VPN ที่ได้รับอนุญาต ไปยังโฮสต์ RDP ที่ใช้ TCP 3389 มาตรฐาน สำหรับโครงสร้างที่ผ่าน 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. เทียบผลในช่วงที่ช้ากับช่วงปกติ กับเวลาที่เกิดอาการและเส้นทางการเชื่อมต่อจริง

   ping 20 ครั้งเป็นการสังเกตระยะสั้น ให้จดความผันผวนของค่าและการไม่ตอบสนอง แต่บางครั้ง 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 ของเซสชันเดียวกัน ให้จดเวลาและ ID ของเซสชันไว้

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

   การสอบถามเซสชันของผู้ใช้คนอื่นอาจต้องใช้สิทธิ์เพิ่มเติม ชื่ออินสแตนซ์มาตรฐานของโปรเซสเป้าหมายคือ SessionID:ProcessID <Process Image> อย่าให้ค่าของผู้ใช้คนอื่นหรือโปรเซสชื่อเดียวกันปนเข้ามาเพราะดูแค่ ID ของเซสชัน ดูเพิ่มเติม: สิทธิ์ของ 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 ต้องตรวจสอบตาม OS โครงสร้างโฮสต์ และสิทธิ์ ในที่นี้เป็นเพียงการอ่านตัวนับที่ใช้ได้ ไม่ใช่ขั้นตอนติดตั้งหรือเปิดใช้งานฟังก์ชัน 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 ทุกตัวสูงสุด 30fps” ให้ตรวจสอบขอบเขตที่ฟังก์ชันและตัวเลขนั้นใช้ได้ก่อนนำไปใช้ ดูเพิ่มเติม: การส่งหน้าจอกับเวิร์กโหลด, เอกสารตัวนับ Graphics

ขอบเขตการใช้ผลการวัด

ไม่ถือว่าตัวเลขต่ำเท่ากับการใช้งานที่ราบรื่น ขอบเขตของแต่ละตัวชี้วัดตรวจสอบได้จากเอกสารของ Microsoft ที่ระบุไว้ในขั้นตอน

การตั้งค่าการสื่อสารและ GPU

เลือกการตั้งค่า UDP หรือ GPU ให้สอดคล้องกับสิ่งที่รู้จากการเปรียบเทียบและการวัด หากสงสัยการสื่อสาร ให้ตรวจสอบวิธีเชื่อมต่อและเส้นทางก่อน หากสงสัยการประมวลผลหน้าจอ ให้ตรวจสอบขั้นที่ใช้ GPU ก่อน

ตรวจสอบ TCP/UDP และเส้นทางการเชื่อมต่อ

เมื่อการเปรียบเทียบและการวัดชี้ว่าการสื่อสารน่าสงสัย ให้ตรวจสอบไคลเอนต์ที่ใช้ เส้นทาง และนโยบายที่มีผลร่วมกับผู้ดูแลระบบ แม้จำเป็นต้องเปลี่ยนการตั้งค่า ก็จำกัดอยู่ในขอบเขตที่ได้รับอนุมัติ และจดค่าก่อนเปลี่ยนกับวิธีกู้คืน ไม่ปิดไฟร์วอลล์หรือการยืนยันตัวตน และไม่เปิดพอร์ต RDP สู่อินเทอร์เน็ตโดยตรง

1. ตรวจสอบ TCP/UDP และเส้นทางจริงจากข้อมูลการเชื่อมต่อ บันทึกการวินิจฉัยของผลิตภัณฑ์ และบันทึกการสื่อสารของผู้ดูแลระบบ

   RDP ใช้ TCP หรือ UDP ตามโครงสร้างและเงื่อนไขการสื่อสาร ใน “Select RDP transport protocols” สามารถเลือกได้ระหว่างการตั้งค่าที่ใช้ UDP หรือ TCP กับการตั้งค่าที่ใช้ TCP อย่างเดียว เนื่องจากมีพฤติกรรมที่ใช้ TCP เมื่อการเชื่อมต่อ UDP ไม่สำเร็จ การเชื่อมต่อสำเร็จเพียงอย่างเดียวจึงไม่บอกวิธีที่ใช้ ดูเพิ่มเติม: การเลือก 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: หาก RDP Shortpath สร้างเส้นทาง UDP ไม่สำเร็จ จะกลับไปใช้การเชื่อมต่อแบบ TCP

ตรวจสอบการใช้ GPU ในการประมวลผลหน้าจอ

ตรวจสอบเมื่อการเปรียบเทียบและการวัดชี้ว่าการประมวลผลหน้าจอน่าสงสัย ให้ตรวจสอบผลการวัดการประมวลผลหน้าจอ รวมถึง OS ไดรเวอร์ นโยบาย และไคลเอนต์ที่รองรับ ไม่เปลี่ยนการตั้งค่าเพียงเพราะมี GPU ติดตั้งอยู่ ให้ได้รับการอนุมัติจากผู้ดูแลระบบและเตรียมการเปลี่ยนกลับไว้ก่อน

1. แยกการเรนเดอร์ของแอปบนเครื่องปลายทาง การเอนโค้ดของ RDP และการดีโค้ดบนฝั่งผู้ใช้ แล้วเลือกขั้นที่น่าสงสัย

   แม้มี GPU ก็ไม่ใช่ทุกขั้นที่ใช้ GPU เอกสารการกำหนดค่าสำหรับ Azure Virtual Desktop ของ Microsoft ก็ตั้งค่าและตรวจสอบการเรนเดอร์ของเซสชันรีโมตกับการเอนโค้ดเฟรมด้วยฮาร์ดแวร์แยกกัน ดูเพิ่มเติม: การกำหนดค่าและตรวจสอบ GPU สำหรับการเรนเดอร์และการเอนโค้ด

2. ตรวจสอบสถานะการใช้งานจริงตามขั้นตอนของผลิตภัณฑ์เป้าหมาย แล้ววัดการกระทำเดิมทั้งก่อนและหลังการเปลี่ยนแปลงที่จำเป็น

   หากเวลาบีบอัดนาน ให้ตรวจสอบการใช้ GPU ในการเอนโค้ด การเปลี่ยนการตั้งค่าเอนโค้ดให้แอปที่รออยู่ในคิวอินพุต ก็เล็งผิดจุด ความอ่านง่ายของตัวอักษรกับความลื่นไหลของวิดีโอ มีวิธีเลือกคุณภาพภาพ ปริมาณการสื่อสาร และภาระการประมวลผลต่างกันด้วย ดูเพิ่มเติม: ความต่างตามเวิร์กโหลด

บันทึกได้ไม่ใช่แค่ว่ามี GPU หรือไม่ แต่รวมถึงว่า GPU ถูกใช้ในขั้นที่มีปัญหา และโหลดกับการตอบสนองของการกระทำเดิมเปลี่ยนไปอย่างไร การเปลี่ยนแปลงที่ไม่ทำให้ดีขึ้น ให้ตรวจสอบกับผู้ดูแลระบบแล้วเปลี่ยนกลับ

flowchart TB
    accTitle: ตรวจสอบการใช้ GPU แยกตามขั้น
    accDescr: แยกการเรนเดอร์ของแอปบนเครื่องปลายทาง การเอนโค้ดของ RDP และการดีโค้ดบนฝั่งผู้ใช้ เนื่องจากแม้มี GPU ก็ไม่ใช่ทุกขั้นที่ใช้ GPU จึงตรวจสอบการใช้ในขั้นที่น่าสงสัย
    A["การเรนเดอร์ของแอปปลายทาง"] --> B["การเอนโค้ดของ RDP"]
    B --> C["การดีโค้ดฝั่งผู้ใช้"]
    C -.- D["ตรวจการใช้ GPU แต่ละขั้น"]

ภาพ 18: แม้มี GPU ก็ไม่ใช่ว่าการเรนเดอร์ การเอนโค้ด และการดีโค้ดจะใช้ GPU ทั้งหมด

การตรวจซ้ำและการส่งต่องาน

ยืนยันการดีขึ้นจากการที่หลังเปลี่ยนแล้วทำการกระทำเดิมได้โดยไม่มีปัญหา และคุณภาพภาพ อุปกรณ์ และฟังก์ชันทางธุรกิจที่จำเป็นยังคงอยู่ โปรดเทียบกับผลหลังเปลี่ยนกลับเป็นเงื่อนไขเดิมด้วย หากเป็นเพียงการฟื้นตัวชั่วขณะ อย่าเพิ่งสรุปสาเหตุ ให้บันทึกโดยรวมช่วงเวลาที่แออัดและงานที่ทำพร้อมกันด้วย

flowchart TB
    accTitle: ลำดับการยืนยันการดีขึ้น
    accDescr: แสดงว่านอกจากตรวจว่าหลังเปลี่ยนแล้วทำการกระทำเดิมได้โดยไม่มีปัญหา ยังต้องตรวจว่าคุณภาพภาพ อุปกรณ์ และฟังก์ชันทางธุรกิจที่จำเป็นยังคงอยู่ เทียบกับผลหลังเปลี่ยนกลับเป็นเงื่อนไขเดิม และไม่สรุปสาเหตุจากการฟื้นตัวชั่วขณะ
    A["ลองการกระทำเดิมหลังเปลี่ยน"] --> B["ตรวจคุณภาพภาพ อุปกรณ์ ฟังก์ชัน"]
    B --> C["เทียบกับผลหลังเปลี่ยนกลับ"]
    C -.- D["ฟื้นชั่วขณะยังสรุปไม่ได้"]

ภาพ 19: นอกจากผลของการกระทำเดิมแล้ว ให้เทียบฟังก์ชันที่จำเป็นและผลหลังเปลี่ยนกลับด้วย

การส่งต่อเมื่อยังแก้ไม่ได้

กรณีที่ไม่ดีขึ้น ไม่เกิดซ้ำ หรือใช้ตัวนับไม่ได้ ก็เป็นผลที่มีประโยชน์เช่นกัน ให้แยกการเปรียบเทียบที่ทำได้กับการตรวจสอบที่ทำไม่ได้ แล้วส่งต่อให้ผู้ดูแลระบบและนักพัฒนาด้วยบันทึกต่อไปนี้ โปรดตัดข้อมูลทางธุรกิจที่ไม่จำเป็นต่อการตรวจสอบ เช่น ชื่อผู้ใช้หรือเครื่องปลายทาง ออกจากล็อกที่แชร์

เวลาและเขตเวลาที่เกิดอาการ:
OS ของเครื่องปลายทาง ไคลเอนต์ที่ใช้และเวอร์ชัน:
เชื่อมต่อตรง/VPN/RD Gateway/Azure Virtual Desktop ฯลฯ:
การกระทำและแอปที่ช้า การตอบสนองของแอปอื่นในเซสชันเดียวกัน:
ความละเอียดและจำนวนจอภาพฝั่งรีโมต:
การคัดลอก การสั่งพิมพ์ ฯลฯ ที่ทำงานพร้อมกัน:
เงื่อนไขเดียวที่เปลี่ยน และผลเมื่อเปลี่ยนกลับ:
โหลดหรือตัวนับที่สังเกตได้บนเครื่องปลายทางและฝั่งผู้ใช้:

ให้ระบุเพิ่มเติมด้วยว่าตรวจสอบ TCP/UDP จริงได้หรือไม่ รายการที่ตรวจสอบไม่ได้เพราะสิทธิ์ไม่พอ เป็นต้น และการตั้งค่าที่ยอมรับได้ในทางธุรกิจ การบอกว่า “Notepad พิมพ์ได้ปกติ แต่ค้างเมื่อเลื่อนดูรูปภาพ” ช่วยให้ผู้รับช่วงต่อตรวจสอบด้วยเงื่อนไขเดียวกันได้มากกว่าการบอกว่า “เครือข่ายช้า”

ผู้ใช้เก็บการกระทำที่ทำให้เกิดซ้ำและผลการเปรียบเทียบไว้ ผู้ดูแลระบบเทียบเส้นทางการเชื่อมต่อ โฮสต์ที่ใช้ร่วมกัน และบันทึกของเซสชัน ข้อเท็จจริงว่ากำลังรออยู่บน RDP เพียงอย่างเดียว ไม่ได้หมายความว่างานที่ทำให้ต้องรอก็คือ RDP ด้วย ดูเพิ่มเติม: การแบ่งหน้าที่ระหว่างโฮสต์กับแบ็กเอนด์

นักพัฒนาแอปให้บันทึกแยกกัน ได้แก่ การรับอีเวนต์อินพุต การเริ่มและสิ้นสุดการประมวลผล DB หรือไฟล์ และการสะท้อนผลไปยัง 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, OS ที่รองรับ อินสแตนซ์ และความหมายของค่าสูงสุด
• 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 โดยแยกการเรนเดอร์กับการเอนโค้ดเฟรม

บทความที่เกี่ยวข้อง

บทความล่าสุดที่มีแท็กเดียวกัน เพื่อเจาะลึกหัวข้อใกล้เคียง

หัวข้อที่เกี่ยวข้อง

นี่คือหน้าหัวข้อที่ใกล้เคียงกับเรื่องนี้ จากบทความนี้ คุณสามารถไปต่อยังบริการที่เกี่ยวข้องและบทความอื่น ๆ ได้

บริการที่เกี่ยวข้องกับหัวข้อนี้

บทความนี้เชื่อมโยงกับหน้าบริการต่อไปนี้ โปรดเริ่มดูจากหน้าที่ใกล้เคียงที่สุด

คำถามที่พบบ่อย

คำถามที่มักพบในการปรึกษาเกี่ยวกับหัวข้อของบทความนี้

ทำไมทดสอบความเร็วได้หลายร้อย Mbps แต่การพิมพ์ใน RDP ยังช้า

ความเร็วในการขนข้อมูลขนาดใหญ่ กับเวลาจนกว่าการตอบสนองต่อการกระทำจะกลับมา เป็นคนละเรื่องกัน การส่งอินพุต การประมวลผลของแอปบนเครื่องปลายทาง การบีบอัดหน้าจอ การรับส่ง และการแสดงผลบนเครื่องฝั่งผู้ใช้ล้วนเกี่ยวข้อง นอกจากนี้ เส้นทางการสื่อสารไปยังเซิร์ฟเวอร์ทดสอบความเร็วกับไปยังเครื่องปลายทาง RDP ก็ต่างกันด้วย

พิมพ์ตัวอักษรได้ตามปกติ แต่เลื่อนหน้าจอแล้วกระตุกอย่างเดียว เป็นปัญหาของเครือข่ายหรือไม่

จำกัดวงไว้ที่เครือข่ายอย่างเดียวไม่ได้ เมื่อการอัปเดตหน้าจอเพิ่มขึ้น อาจมีบางจุดตามไม่ทัน ไม่ว่าจะเป็นการเรนเดอร์และการบีบอัดบนเครื่องปลายทาง การสื่อสาร หรือการดีโค้ดและการแสดงผลบนเครื่องฝั่งผู้ใช้ ให้เปลี่ยนความละเอียดหรือจำนวนจอภาพฝั่งรีโมตทีละอย่างแล้วเปรียบเทียบ และหากจำเป็นจึงตรวจสอบตัวนับที่เกี่ยวกับการเรนเดอร์

ถ้า ping เร็ว แสดงว่าการสื่อสารของ RDP ปกติหรือไม่

ตัดสินจากสิ่งนั้นอย่างเดียวไม่ได้ ping วัดการตอบสนองต่อ ICMP ไม่ได้วัดการส่งหน้าจอของ RDP หรือการประมวลผลของแอป ในโครงสร้างที่ใช้ RD Gateway เป็นต้น เส้นทางก็อาจไม่ตรงกัน แม้ไม่มีการตอบกลับ ก็โปรดแยกระหว่างการที่ ICMP ถูกบล็อกกับการที่ RDP เองเชื่อมต่อไม่ได้

User Input Delay คือเวลาตั้งแต่กดแป้นจนตัวอักษรปรากฏใช่หรือไม่

ไม่ใช่ เป็นตัวนับที่วัดเวลารอตั้งแต่อินพุตเข้าคิวบนเครื่องปลายทางจนโปรเซสดึงออกไป ไม่ใช่ความหน่วงที่ผู้ใช้รู้สึกซึ่งรวมการไป-กลับของการสื่อสาร การประมวลผลของแอปหลังดึงอินพุตออกไป ไปจนถึงการบีบอัด การดีโค้ด และการแสดงผลหน้าจอ

เมื่อ RDP หน่วง ควรปิดใช้งาน UDP หรือไม่

เราไม่แนะนำโดยทั่วไป ให้ตรวจสอบวิธีเชื่อมต่อและเส้นทางจริง รวมถึงนโยบายที่มีผลก่อน บางกรณีใช้ UDP ไม่ได้และกำลังถอยกลับไปใช้ TCP อยู่แล้ว และการเปลี่ยนเป็น TCP อย่างเดียวไม่ได้ทำให้เร็วขึ้นเสมอไป ให้เปรียบเทียบโดยจัดเงื่อนไขให้เหมือนกันภายใต้การอนุญาตของผู้ดูแลระบบ และเปลี่ยนสิ่งที่ไม่จำเป็นกลับคืน

โปรไฟล์ผู้เขียน

หน้าแนะนำผู้เขียนบทความ

Go Komura

ผู้แทนของ KomuraSoft LLC

เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ Windows ที่ปรึกษาเทคนิค และการตรวจสอบบั๊ก โดยเฉพาะงานที่มีระบบเดิมอยู่ และการตรวจสอบความขัดข้องที่มองเห็นสาเหตุได้ยาก