Đặt ngân sách độ trễ cho lưu lượng thời gian thực qua VPN
Hãy bắt đầu từ hạn chót mà ứng dụng phải đáp ứng, rồi đo độ trễ một chiều và độ biến động trong những điều kiện đã nêu. Một giá trị trung bình không có ngưỡng cho gói đến muộn không chứng minh được gì.
Khiếu nại về VPN thời gian thực cần một hạn chót để đối chiếu thất bại, và „độ trễ thấp“ không phải là hạn chót đó. Hãy quyết định cuộc trò chuyện hoặc phiên từ xa phải cung cấp điều gì, rồi đo đường truyền so với yêu cầu đó trong những điều kiện đã nêu. Không có ngưỡng cho gói đến muộn, mọi kết quả đều có thể tranh cãi. Phân bổ dưới đây là một quyết định thiết kế, và nó tồn tại để phép đo có thứ gì đó để trả lời.
Viết hạn chót trước khi chạm vào một đầu dò
Hạn chót đến từ ứng dụng và người dùng của nó, không phải từ trang tiếp thị của nhà cung cấp. Cuộc gọi thoại trực tiếp, phiên máy tính để bàn từ xa và bản sao lưu hằng đêm chịu được thời gian chờ hoàn toàn khác nhau, và thất bại đáng kể thường nằm ở đuôi chứ không phải ở trung vị. Hãy ghi con số đó cùng với khối lượng công việc mà nó thuộc về.
Sau đó phân bổ nó. Việc bắt gói và đóng gói tiêu tốn một phần ngân sách, đường truyền truy cập và đường hầm tiêu tốn phần khác, bộ đệm khử biến động của bên nhận cố ý giữ gói lại, và xử lý ứng dụng lấy phần còn lại. Gọi tên các giai đoạn đó giữ cho mã hóa đường hầm ở đúng tỷ lệ thay vì biến nó thành nghi phạm mặc định cho mọi gói chậm.
Cuối cùng, định nghĩa hợp đồng đo trong bốn dòng: các điểm đầu cuối và hướng, hình dạng lưu lượng, điều kiện trong lúc chạy, và kết quả bạn sẽ báo cáo. Một mẫu Chủ nhật yên tĩnh và một mẫu thứ Ba đầy tải trả lời những câu hỏi khác nhau, nên hãy nêu rõ bạn đã thu thập mẫu nào. Nếu bạn không điền được cả bốn dòng, lần chạy chưa sẵn sàng bắt đầu. Danh sách kiểm tra đó cũng là thứ khiến hai báo cáo so sánh được với nhau sau nhiều tháng, khi không ai còn nhớ đường truyền đang chở thêm thứ gì.
Chia ngân sách cho từng giai đoạn
Bảng này là công cụ hỗ trợ lập kế hoạch, không phải dữ liệu đã thu thập. Điền người phụ trách cho từng hàng trước lần đo đầu tiên, vì người phụ trách là người bạn gọi khi giai đoạn đó vượt phần của nó.
| 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 |
Hai hàng thường khiến người ta ngạc nhiên. Bộ đệm bên nhận không phải lỗi khi nó thêm độ trễ, vì nó đang làm đúng công việc được cấu hình cho nó. Và phần của đường hầm thường nhỏ hơn hàng đợi phía trước nó, đặc biệt trên một đường lên bị bão hòa trong lúc tải lên.
Khi một giai đoạn không có người phụ trách, ngân sách chỉ là hư cấu. Hãy chỉ định ai đó trước khi đo, nếu không bạn sẽ dành cuộc họp tiếp theo để tranh cãi con số của ai sai.
Đo độ trễ một chiều bằng một đồng hồ trung thực
Độ trễ một chiều là con số mà hạn chót quan tâm, và nó cần đồng hồ được đồng bộ ở cả hai đầu. số đo độ trễ một chiều yêu cầu bạn báo cáo phương pháp đồng bộ, độ phân giải và độ lệch ước tính cùng với kết quả. Hai máy chủ không đồng bộ có thể tạo ra một con số rất chính xác cho một đại lượng sai.
Hãy bắt vài trăm gói thay vì một nhúm, và ghi lại trạng thái đồng hồ cùng lúc:
$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3Thời gian khứ hồi là một phép đo riêng, không phải hai giá trị một chiều cộng lại. Chia đôi RTT giả định đường đi đối xứng và hàng đợi đối xứng, và một đường hầm trên đường lên di động thường xuyên phá vỡ cả hai giả định. Hãy báo RTT là RTT và giữ nó ngoài ngân sách một chiều.
Báo cáo phần đuôi và các gói đến muộn
Tóm tắt phân bố: trung vị, bách phân vị 95 và 99, trường hợp xấu nhất, mất mát, và số gói đến muộn hơn mức hạn chót cho phép. Giá trị trung bình là con số ít hữu ích nhất trong các con số đó cho khối lượng công việc thời gian thực, vì một trung bình mượt có thể che giấu phần đuôi phá hỏng mỗi cuộc gọi thứ ba.
Độ biến thiên trễ chảy trực tiếp vào bộ đệm bên nhận. Đệm nhiều hơn che giấu biến thiên và thêm chờ đợi, nên một luồng có thể trông ổn định trong khi vượt hạn chót của nó. Hãy chọn một công thức biến thiên, nêu khoảng thời gian bạn đã đo, và giữ nó nhất quán giữa các lần chạy.
Lặp lại lần chạy với lưu lượng cắt ngang đại diện. Một đường truyền đáp ứng ngân sách khi rảnh và trượt nó trong cửa sổ sao lưu đã cho bạn biết điều gì đó hữu ích về lập lịch, mà không phép đo yên tĩnh đơn lẻ nào tiết lộ được. Ghi lại các điều kiện bên cạnh kết quả, vì nếu không kỹ sư tiếp theo sẽ so sánh hai mẫu chưa từng so sánh được.
Chấp nhận thiết kế khi phần đuôi đo được nằm trong ngân sách dưới khối lượng công việc bạn thực sự chạy, và từ chối nó kèm tên giai đoạn đã vượt trong báo cáo.