DPC latency สูงไม่ได้แปลว่าเส้นทาง VPN ช้า

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

มีการวัดสามอย่างในเกมนี้ และมันไม่ได้แบ่งขอบเขตเดียวกัน

สามตัวเลข สามขอบเขต

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

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

ตัวเลขสูงในหมวดหนึ่งเป็นเบาะแส ไม่เคยเป็นการวินิจฉัย

อ่านคำนิยามเบื้องหลังพาดหัว

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

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

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

วางทุกการสังเกตไว้ในหน้าต่างเดียว

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

wpr -start CPU -filemode
wpr -stop vpn-trace.etl
xperf -i vpn-trace.etl -a dpcisr -o dpc.txt

จากนั้นเปิดการติดตามในเครื่องมือวิเคราะห์และเรียงตามระยะเวลาภายในหน้าต่างนั้น ไม่ใช่ทั้งการบันทึก แนวทางการวิเคราะห์ CPU อธิบายมุมมองระยะเวลา DPC/ISR ที่กำหนดเวลาให้กับโมดูลและฟังก์ชัน

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

เปลี่ยนองค์ประกอบที่หลักฐานชี้

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

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

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