Tải xuống nhanh, vậy tại sao mỗi cú nhấp lại chậm?

Tải nhanh một tệp lớn rồi thấy mỗi cú nhấp đều chậm không phải là mâu thuẫn. Dung lượng cho biết mỗi giây có thể di chuyển bao nhiêu; thời gian khứ hồi cho biết một lần trao đổi kéo dài bao lâu trước khi có điều gì hữu ích xảy ra. Cải thiện cái đầu không giúp gì cho cái sau, và cái sau là thứ một người nhận ra khi gõ, nhấp hay nói. Hãy đo lời phàn nàn, không phải kết nối.

Tệp nhanh, nhấp chậm: hai con số khác nhau

Một lần truyền hàng loạt giữ dữ liệu chuyển động liên tục, nên nó có thể báo tốc độ lành mạnh ngay cả khi từng yêu cầu riêng lẻ đang chờ. Nhiều bài đo cũng mở nhiều kết nối cùng lúc, điều này làm tăng con số tổng trong khi một yêu cầu vẫn chậm. Hai kết quả tương thích với nhau, và việc trích con số cao hơn cho người dùng đang phàn nàn về độ trễ là cách mất niềm tin.

Tải một trang là một chuỗi trao đổi nhỏ: phân giải tên, thiết lập kết nối, một yêu cầu, một phản hồi, rồi các yêu cầu phụ thuộc. Mỗi bước lại trả thời gian khứ hồi, nên một đường có độ trễ cao vẫn chậm dù dung lượng dồi dào.

Đường hầm thêm hành trình và xử lý của riêng nó, và tuyến đường quan trọng hơn nhãn trên bản đồ. Hai lối ra trong cùng một quốc gia có thể có những đường đi rất khác nhau tới một đích. Chênh lệch hai mươi mili giây đủ để đổi cảm nhận về một trang, dù nó hầu như không nhúc nhích con số thông lượng. Vì vậy việc chọn lối ra nên theo một mẫu độ trễ chứ không phải biểu tượng lá cờ.

Đo lời phàn nàn, không phải kết nối

Chọn phép đo khớp với câu người dùng nói. Tải chậm cần tốc độ bền bỉ đúng hướng; cuộc gọi giật cần thống kê của chính ứng dụng đó; trang khởi động chậm cần thời gian phân giải tên và thiết lập.

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

Lệnh thứ nhất cho một mẫu khứ hồi tới máy chủ phản hồi có thể đoán trước, lệnh thứ hai báo thời gian tới byte đầu và tốc độ bền bỉ của một kết nối, và lệnh thứ ba đo thông lượng tổng với bốn luồng song song. Hãy chạy chúng tới cùng một đích vào cùng một thời điểm trong ngày, vì so một mẫu buổi sáng với một mẫu buổi tối tạo ra một câu chuyện chứ không phải phép đo.

Giữ đích cố định khi so các lối ra. Đổi cả máy chủ lẫn đường hầm biến một biến số thành hai, và kết quả không thể cho bạn biết cái nào quan trọng. Chạy mỗi lối ra ít nhất ba lần, vì một mẫu đơn lẻ thường rơi vào lúc đổi tuyến hoặc một phút ồn ào. Trung vị hữu ích hơn trường hợp tốt nhất.

Coi ICMP là manh mối chứ không phải câu trả lời. Một máy chủ phản hồi có thể xử lý các yêu cầu echo trên một đường khác với đường ứng dụng của bạn dùng, và một phản hồi bị mất không phải bằng chứng mọi ứng dụng đều mất gói.

Độ trễ dưới tải là vấn đề hàng đợi

Mẫu khiến người ta bối rối nhất là một kết nối có vẻ ổn khi rảnh và không dùng được trong lúc sao lưu. Đó là hàng đợi, không phải dung lượng. Một đường lên bị bão hòa dựng bộ đệm trước mọi gói khác, nên một lần gõ phím chờ sau một phần của lần tải lên.

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

Lệnh thứ nhất lấy mẫu độ trễ ở nền trong khi lệnh thứ hai làm bão hòa chiều ngược lại. Nếu thời gian ping nhảy vọt trong lúc truyền rồi hồi phục sau đó, bạn đã tái tạo bufferbloat chứ không phát hiện lỗi định tuyến. Cách sửa thường là một cài đặt quản lý hàng đợi, tốc độ nền thấp hơn hoặc đưa lần truyền lớn ra khỏi đường tương tác.

Giảm lưu lượng nền tùy chọn thường giúp nhiều hơn đổi quốc gia lối ra. Nó cũng rẻ hơn, khả nghịch và kiểm chứng được trong một phút. Hãy lên lịch các lần tải lên lớn ngoài giờ làm việc nếu không quản lý được hàng đợi, và giới hạn tốc độ của chúng nếu chúng phải chạy ban ngày. Cài đặt quản lý hàng đợi là cách sửa tốt hơn khi bộ định tuyến hỗ trợ.

Đổi một thứ và so cái tương đương với cái tương đương

Với độ trễ cao khi rảnh, hãy so các lối ra trong khi giữ đích cố định, rồi so các tuyến cho ứng viên tốt nhất. Với thông lượng thấp và ổn định, hãy nhìn dung lượng, tải máy chủ và xử lý máy khách, vì đó là các giới hạn khác nhau.

Ghi lại bạn đã đo gì, với đích nào, vào lúc nào và với cài đặt nào. Một so sánh thiếu bốn sự kiện đó không thể lặp lại, và người tiếp theo sẽ bắt đầu từ số không.

Sau đó khớp công cụ với khẳng định trong phiếu. "Internet chậm" không phải phép đo; "byte đầu mất 900 ms tới máy chủ này trong khi thông lượng tốt" là một phép đo, và nó chỉ thẳng vào độ trễ chứ không phải dung lượng.