การดาวน์โหลดของคุณเร็ว แล้วทำไมทุกคลิกถึงรู้สึกช้า

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

ไฟล์เร็ว คลิกช้า: ตัวเลขสองแบบที่ต่างกัน

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

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

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

วัดข้อร้องเรียน ไม่ใช่วัดการเชื่อมต่อ

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

ping -c 20 10.60.0.5
curl -sS -o /dev/null -w 'ttfb=%{time_starttransfer} rate=%{speed_download}\n' https://files.plant.example/1gb.bin
iperf3 -c 10.60.0.5 -t 10 -P 4

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

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

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

ความหน่วงภายใต้โหลดเป็นปัญหาคิว

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

ping -c 20 10.60.0.5 &
iperf3 -c 10.60.0.5 -t 20 -R -b 20M

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

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

เปลี่ยนสิ่งเดียวและเทียบสิ่งที่เหมือนกัน

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

จดบันทึกว่าวัดอะไร เทียบกับปลายทางใด เวลาใด และด้วยการตั้งค่าใด การเปรียบเทียบที่ไม่มีสี่ข้อนั้นทำซ้ำไม่ได้ และคนถัดไปจะเริ่มจากศูนย์

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