กำหนดงบเวลาหน่วงสำหรับทราฟฟิกแบบเรียลไทม์ผ่าน VPN
เริ่มจากกำหนดเวลาที่แอปต้องทำให้ได้ แล้ววัดความหน่วงทางเดียวและความแปรปรวนของดีเลย์ภายใต้เงื่อนไขที่ระบุ ค่าเฉลี่ยที่ไม่มีเกณฑ์สำหรับแพ็กเก็ตมาสายไม่ได้พิสูจน์อะไรเลย
ข้อร้องเรียนเรื่อง VPN แบบเรียลไทม์ต้องมีกำหนดเวลาที่จะล้มเหลวได้ และ „ความหน่วงต่ำ“ ไม่ใช่กำหนดเวลานั้น ตัดสินใจว่าการสนทนาหรือเซสชันระยะไกลต้องส่งมอบอะไร แล้ววัดเส้นทางเทียบกับข้อกำหนดนั้นภายใต้เงื่อนไขที่ระบุ หากไม่มีเกณฑ์แพ็กเก็ตมาสาย ทุกผลลัพธ์ก็เถียงกันได้ การจัดสรรด้านล่างเป็นการตัดสินใจเชิงออกแบบ และมีไว้เพื่อให้การวัดมีอะไรให้ตอบ
เขียนกำหนดเวลาให้เสร็จก่อนแตะหัววัด
กำหนดเวลามาจากแอปพลิเคชันและผู้ใช้ ไม่ใช่จากหน้าตลาดของผู้ขาย สายเสียงสด เซสชันเดสก์ท็อประยะไกล และการสำรองข้อมูลตอนกลางคืนทนเวลารอที่ต่างกันโดยสิ้นเชิง และความล้มเหลวที่สำคัญมักอยู่ที่หางการกระจาย ไม่ใช่ค่ามัธยฐาน เขียนตัวเลขนั้นคู่กับภาระงานที่มันเป็นของ
จากนั้นจัดสรรลงไป การจับแพ็กเก็ตและการทำแพ็กเก็ตใช้ส่วนหนึ่งของงบ ส่วนลิงก์เชื่อมต่อและอุโมงค์ใช้ส่วนอื่น บัฟเฟอร์ลดความแปรปรวนของฝั่งรับตั้งใจหน่วงแพ็กเก็ตไว้ และการประมวลผลของแอปใช้ที่เหลือ การตั้งชื่อขั้นตอนเหล่านั้นทำให้การเข้ารหัสของอุโมงค์อยู่ในสัดส่วนที่ควร แทนที่จะเป็นผู้ต้องสงสัยโดยอัตโนมัติสำหรับทุกแพ็กเก็ตที่ช้า
สุดท้ายนิยามสัญญาการวัดในสี่บรรทัด: ปลายทางและทิศทาง รูปร่างของทราฟฟิก เงื่อนไขระหว่างการทดสอบ และผลลัพธ์ที่จะรายงาน ตัวอย่างวันอาทิตย์ที่เงียบกับตัวอย่างวันอังคารที่โหลดหนักตอบคำถามคนละข้อ ดังนั้นระบุว่าคุณเก็บอันไหน หากเติมทั้งสี่บรรทัดไม่ได้ การทดสอบยังไม่พร้อมเริ่ม รายการตรวจสอบนั้นยังทำให้รายงานสองฉบับเทียบกันได้ในอีกหลายเดือนต่อมา เมื่อไม่มีใครจำได้ว่าลิงก์ยังพาอะไรอีก
แบ่งงบประมาณให้ทุกขั้นตอน
ตารางนี้เป็นเครื่องช่วยวางแผน ไม่ใช่ข้อมูลที่เก็บมา เติมชื่อผู้รับผิดชอบในแต่ละแถวก่อนการวัดครั้งแรก เพราะผู้รับผิดชอบคือคนที่คุณโทรหาเมื่อขั้นตอนนั้นเกินส่วนของตน
| Stage | What it contributes | Who owns it |
|---|---|---|
| Capture and packetization | Encoder frame size, aggregation | Application owner |
| Tunnel and transit | Encryption, queueing, path length | Network owner |
| Receiver buffer | Deliberate waiting to absorb variation | Application owner |
| Application processing | Decode and render time | Application owner |
สองแถวมักทำให้คนแปลกใจ บัฟเฟอร์ฝั่งรับไม่ใช่ความผิดเมื่อมันเพิ่มความหน่วง เพราะมันกำลังทำหน้าที่ที่ถูกตั้งค่าไว้ และส่วนของอุโมงค์มักเล็กกว่าคิวที่อยู่ข้างหน้า โดยเฉพาะบนอัปลิงก์ที่อิ่มตัวระหว่างการอัปโหลด
เมื่อขั้นตอนใดไม่มีผู้รับผิดชอบ งบก็เป็นเรื่องแต่ง ตั้งคนหนึ่งก่อนวัด ไม่อย่างนั้นคุณจะใช้การประชุมครั้งถัดไปเถียงกันว่าเลขของใครผิด
วัดความหน่วงทางเดียวด้วยนาฬิกาที่ซื่อสัตย์
ความหน่วงทางเดียวคือตัวเลขที่กำหนดเวลาสนใจ และต้องมีนาฬิกาที่ซิงค์กันทั้งสองฝั่ง ตัวชี้วัดความหน่วงทางเดียว กำหนดให้คุณรายงานวิธีการซิงค์ ความละเอียด และความเอนเอียงโดยประมาณควบคู่กับผลลัพธ์ โฮสต์สองเครื่องที่ไม่ได้ซิงค์กันอาจให้ตัวเลขที่แม่นยำมากสำหรับปริมาณที่ผิด
เก็บแพ็กเก็ตสักสองสามร้อยแพ็กเก็ตแทนที่จะหยิบมือเดียว และบันทึกสถานะนาฬิกาในเวลาเดียวกัน:
$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3เวลาสื่อสารไปกลับเป็นการวัดแยก ไม่ใช่ค่าทางเดียวสองค่าที่บวกกัน การหารครึ่ง RTT สมมติว่าเส้นทางสมมาตรและคิวสมมาตร และอุโมงค์บนอัปลิงก์มือถือทำลายสมมติฐานทั้งสองเป็นปกติ รายงาน RTT ว่าเป็น RTT และเก็บมันไว้นอกงบทางเดียว
รายงานหางการกระจายและแพ็กเก็ตที่มาสาย
สรุปการกระจาย: ค่ามัธยฐาน เปอร์เซ็นไทล์ที่ 95 และ 99 กรณีแย่ที่สุด การสูญหาย และจำนวนแพ็กเก็ตที่มาถึงช้ากว่ากำหนดเวลาที่อนุญาต ค่าเฉลี่ยเป็นตัวเลขที่ใช้น้อยที่สุดในบรรดาตัวเลขเหล่านั้นสำหรับภาระงานเรียลไทม์ เพราะค่าเฉลี่ยที่เรียบเนียนอาจซ่อนหางที่ทำลายทุกสายที่สาม
ความแปรปรวนของความหน่วงไหลตรงเข้าสู่บัฟเฟอร์ฝั่งรับ บัฟเฟอร์ที่มากขึ้นซ่อนความแปรปรวนและเพิ่มการรอ ดังนั้นสตรีมอาจดูนิ่งในขณะที่เกินกำหนดเวลา เลือกสูตรความแปรปรวน ระบุช่วงเวลาที่วัด และทำให้สอดคล้องกันระหว่างการทดสอบ
ทำการทดสอบซ้ำด้วยทราฟฟิกตัดขวางที่เป็นตัวแทน เส้นทางที่ผ่านงบเมื่อว่างและพลาดระหว่างหน้าต่างสำรองข้อมูลได้บอกสิ่งที่มีประโยชน์เกี่ยวกับการจัดตาราง ซึ่งการวัดที่เงียบเพียงครั้งเดียวไม่เปิดเผย บันทึกเงื่อนไขไว้ข้างผลลัพธ์ เพราะไม่อย่างนั้นวิศวกรคนถัดไปจะเทียบสองตัวอย่างที่ไม่เคยเทียบกันได้
ยอมรับการออกแบบเมื่อหางที่วัดได้พอดีกับงบภายใต้ภาระงานที่คุณรันจริง และปฏิเสธพร้อมระบุขั้นตอนที่เกินในรายงาน