Tính tốc độ truyền hữu ích mà cửa sổ phân phối của bạn yêu cầu, sau đó đo toàn bộ đường truyền. Dung lượng cổng, thời gian khứ hồi, hành vi TCP, lưu trữ và xử lý ứng dụng đều ảnh hưởng đến kết quả. Dùng các kiểm tra có kiểm soát với mức đồng thời thực tế và lặp lại chúng qua ứng dụng thực tế trước khi chọn hạng mạng.
Chuyển cửa sổ phân phối thành tốc độ
Bắt đầu với lượng dữ liệu ứng dụng hữu ích và thời gian sẵn có để phân phối nó. Dùng đơn vị thập phân, truyền 2 TB trong hai giờ yêu cầu khoảng 278 MB mỗi giây tải trọng, tức 2.22 Gbps, trước khi tính đến chi phí giao thức và gián đoạn. Phép tính này là ví dụ lập kế hoạch, không phải kết quả dịch vụ đã đo.
Bao gồm các truyền tải trùng lặp. Một bản xuất theo lịch, lượt tải xuống của khách hàng và tải lên bản sao lưu có thể chia sẻ tài nguyên ngay cả khi tổng hàng tháng của chúng có vẻ khiêm tốn. Viết mô hình giai đoạn bận rộn, không chỉ trung bình hàng tháng. Chỉ rõ hướng nào quan trọng và liệu truyền tải thất bại phải khởi động lại hay có thể tiếp tục; hành vi đó ảnh hưởng đến lượng công việc hệ thống thực hiện.
Tách dung lượng cổng khỏi thông lượng hữu ích
Cổng máy chủ mô tả dung lượng liên kết. Thông lượng hữu ích mô tả dữ liệu được ứng dụng của bạn phân phối trong một khoảng thời gian quan sát. Mã hóa, đóng gói giao thức, truyền lại, hoạt động lưu trữ và công việc tại bên nhận chiếm một phần đường truyền đó. Do đó, một cổng 10 Gbps được liệt kê không chứng minh rằng ứng dụng sẽ liên tục phân phối 10 Gbps tải trọng.
IETF RFC 6349 phân biệt cụ thể việc kiểm tra đường mạng với việc xem xét hiệu năng TCP. Sử dụng sự tách biệt này trong chẩn đoán của riêng bạn. Trước tiên xác nhận rằng các điểm cuối và tuyến là phù hợp, sau đó điều tra vận chuyển và ứng dụng. Tăng cổng đã mua không khắc phục được bên nhận ghi dữ liệu chậm hoặc ứng dụng xử lý từng yêu cầu một.
Hiểu vì sao thời gian khứ hồi quan trọng
TCP kiểm soát lượng dữ liệu có thể còn đang truyền trước khi xác nhận quay lại. Tích băng thông-độ trễ đưa ra thang đo hữu ích cho điều này: tốc độ nhân với thời gian khứ hồi. Một đường 10 Gbps giả định với 40 mili giây độ trễ khứ hồi đại diện cho khoảng 50 MB đang truyền. Phép tính này giải thích vì sao độ trễ và hành vi vận chuyển thuộc về lập kế hoạch tốc độ cao.
Kết quả không phải là chỉ dẫn áp dụng một cài đặt socket tùy ý. Hệ điều hành, kiểm soát tắc nghẽn, cửa sổ được thương lượng và đường thực tế ảnh hưởng đến hành vi. Xác minh tài liệu phần mềm hiện tại và kiểm tra số đo trước khi tinh chỉnh. Nhiều kết nối song song hơn có thể cải thiện thông lượng tổng hợp trong một số trường hợp, nhưng chúng cũng có thể che giấu hành vi của từng truyền tải mà ứng dụng của bạn phụ thuộc vào.
Xây dựng ma trận kiểm tra có kiểm soát
Chỉ sử dụng các điểm cuối bạn sở hữu hoặc được phép kiểm tra. Thống nhất cửa sổ và tốc độ kiểm tra để bài tập không làm gián đoạn dịch vụ bình thường. Các công cụ như iperf3 cung cấp hướng, thời lượng và luồng song song có thể cấu hình; tài liệu chính thức định nghĩa các kiểm soát đó. Ghi lại phiên bản, điểm cuối, bối cảnh tuyến và cài đặt cùng kết quả để nhà vận hành khác có thể tái tạo.
Bắt đầu với một luồng, sau đó thêm mức đồng thời đại diện. Chạy cả hai hướng nếu ứng dụng phụ thuộc vào cả hai. Ma trận minh họa này tách biệt các câu hỏi mà một kết quả tiêu đề duy nhất sẽ trộn lẫn. Giữ kết quả thô ở chế độ riêng tư khi chúng tiết lộ địa chỉ nội bộ hoặc chi tiết vận hành, và chỉ công bố các số đo cần thiết cho quyết định.
| Kiểm tra | Nội dung điều tra | Những gì nó không chứng minh |
|---|---|---|
| Một luồng vận chuyển | Hành vi đường một luồng | Phân phối ứng dụng tổng hợp |
| Nhiều luồng song song | Đồng thời và giới hạn tổng hợp | Tốc độ truyền của một khách hàng |
| Truyền ứng dụng | Lưu trữ, giao thức và phần mềm cùng nhau | Hiệu năng cho mọi tập dữ liệu |
| Lặp lại giai đoạn bận rộn | Biến động dưới hoạt động thực tế | Đảm bảo thông lượng vĩnh viễn |
Xem các điểm cuối trong quá trình kiểm tra
Ghi lại mức sử dụng CPU, áp lực bộ nhớ, hoạt động lưu trữ và bộ đếm lỗi ở cả hai đầu. Kết quả truyền tải không có quan sát điểm cuối có thể khiến ràng buộc thực sự vô hình. Kiểm tra xem một tiến trình hoặc CPU có bị bão hòa trong khi những cái khác nhàn rỗi không. Tránh thay đổi nhiều cài đặt cùng lúc, vì điều đó khiến khó xác định điều chỉnh nào đã giúp ích.
Tách biệt kiểm tra dựa trên bộ nhớ với kiểm tra đọc và ghi dữ liệu thực. Cái trước có thể giúp điều tra đường vận chuyển; cái sau phản ánh nhiều hơn công việc của ứng dụng. Nếu kết quả khác biệt rõ rệt, hãy kiểm tra lưu trữ và xử lý thay vì coi con số dựa trên bộ nhớ là lời hứa phân phối. Cả hai số đo đều có thể hữu ích khi phạm vi của chúng rõ ràng.
Kiểm tra ứng dụng với tải trọng thực tế
Một bản xuất HTTP, luồng sao chép được mã hóa và phiên truyền tệp có các mẫu xử lý khác nhau. Dùng kích thước tệp, tốc độ yêu cầu và cài đặt mã hóa đại diện. Bao gồm thời gian chuẩn bị dữ liệu trước khi byte đầu tiên được gửi khi người dùng chờ bước đó. Phân biệt độ trễ phản hồi đầu tiên với thời gian hoàn thành thay vì báo cáo cái này như cái kia.
Lặp lại kiểm tra qua đủ khoảng thời gian để thấy biến động và giữ đường cơ sở trước khi thay đổi cấu hình. Đối với bản xuất 2 TB giả định, so sánh thời gian hoàn thành thực tế với cửa sổ hai giờ và để biên độ cho gián đoạn. Chọn cải tiến dựa trên nút thắt đã quan sát thay vì nhân dung lượng cổng mà không có lý do.
Dùng kết quả để chọn cấu hình
Đầu ra hữu ích là yêu cầu tài nguyên kèm bằng chứng: tốc độ tải trọng đã đo, thời gian hoàn thành chấp nhận được, mức đồng thời dự kiến và giai đoạn giới hạn đã biết. So sánh các biến thể mạng SwissOctet với yêu cầu đó, bao gồm hạn mức lưu lượng và thông số CPU cùng lưu trữ. Chỉ vị trí không quyết định tuyến hoặc độ trễ đầu cuối đến mọi bên nhận.
Giữ quy trình kiểm tra sau khi triển khai. Tái sử dụng nó khi tập dữ liệu tăng, phần mềm thay đổi hoặc người dùng chuyển sang mạng khác. Đường cơ sở có thể lặp lại giúp chẩn đoán sự cố hiệu năng dễ hơn và đưa ra lý do chắc chắn hơn để thay đổi cấu hình so với một bài kiểm tra tốc độ riêng lẻ hoặc mức tối đa được quảng cáo.
Danh sách kiểm tra thực tế của bạn.
- Tính tốc độ tải trọng từ khối lượng và thời hạn.
- Mô hình hóa các truyền tải trùng lặp và hướng.
- Thống nhất điểm cuối kiểm tra được phép và giới hạn.
- So sánh một luồng, đồng thời và kiểm tra ứng dụng.
- Quan sát cả hai điểm cuối trong khi kiểm tra.
- Giữ đường cơ sở có thể lặp lại và biên độ hữu ích.
Những chi tiết quan trọng.
Cửa sổ TCP lớn hơn có luôn khắc phục truyền chậm không?+
Không. Trước tiên hãy chẩn đoán đường truyền và điểm cuối. Lưu trữ, CPU, mất mát và hành vi ứng dụng có thể chiếm ưu thế, và tinh chỉnh vận chuyển phải phù hợp với hệ thống thực tế.
Vì sao kiểm tra một luồng và nhiều luồng?+
Chúng trả lời các câu hỏi khác nhau. Dung lượng tổng hợp có thể cao hơn tốc độ của một truyền tải; mức đồng thời của ứng dụng quyết định kết quả nào quan trọng.
Tôi có thể chạy kiểm tra dung lượng với bất kỳ máy chủ công khai nào không?+
Sử dụng các điểm cuối bạn kiểm soát hoặc có quyền kiểm tra. Thống nhất thời lượng, tốc độ và thời điểm để phép đo không làm gián đoạn các dịch vụ không liên quan.
Đến nguồn.
Các tài liệu tham khảo này hỗ trợ các khái niệm kỹ thuật trong hướng dẫn này. Hãy theo dõi tài liệu hiện hành trước khi thay đổi hệ thống sản xuất.
- IETF RFC 6349: Khung kiểm tra thông lượng TCP datatracker.ietf.org
- ESnet: Gọi iperf3 software.es.net
Hướng dẫn biên tập bởi SwissOctet. Các ví dụ chỉ mang tính minh họa. Thông số dịch vụ, tùy chọn có sẵn và điều kiện hợp đồng phải được xác minh riêng.