Độ trễ ghi giữa điểm bắt đầu được kiểm soát và điểm cuối không được kiểm soát

Đây có thể là một câu hỏi khắc phục sự cố rất cơ bản, nhưng đáng để hỏi để đảm bảo rằng tôi đang kiểm tra mọi thứ theo cách chính xác và diễn giải kết quả một cách hiệu quả.

Tôi có điểm bắt đầu được kiểm soát (cụm máy chủ dưới sự kiểm soát của tôi) và điểm cuối không được kiểm soát (trung tâm dữ liệu tôi không có quyền truy cập vật lý hoặc từ xa). Là một phần của xử lý sự cố thông thường, tôi thường cần thiết lập các số trễ.

Hiện tại, tôi đang sử dụng máy vẽ ping hoặc chỉ là một kiểu cũ liên tục pinghaytracert

Nếu tôi đang cố gắng thiết lập các số đầu cuối thực tế hơn (phần mềm tôi đang làm việc là phần mềm cơ sở dữ liệu) đôi khi tôi sẽ sử dụng Fiddler 2 để nắm bắt lưu lượng truy cập web và so sánh một số bộ định thời ở đó (như ClientDoneRequest-> ServerBeginResponse) với có được một kết thúc đầy đủ để kết thúc thời gian.

Các bạn nhìn gì khi xác định số cho độ trễ mạng thẳng?

Nửa câu hỏi sau của bạn dường như cho thấy bạn đang tìm kiếm các số liệu về độ trễ có tính đến quá trình hình thành dữ liệu của lớp ứng dụng, trong trường hợp đó "ping" sẽ không giúp ích nhiều khi xem xét không có nhiều dữ liệu được tạo thành trong một ping gói.

Mọi người trong mạng thường dựa vào ping vì đó là cách tương đối nhẹ và đáng tin cậy để tạo ra một lượng dữ liệu ngẫu nhiên nhất định để kiểm tra khả năng tiếp cận và độ trễ cho một đường dẫn nhất định. Chẳng hạn, một ứng dụng sử dụng các cuộc gọi HTTP sẽ hoạt động khác đi vì HTTP không giống với ICMP.

Nếu bạn quan tâm đến các số liệu về độ trễ mạng chung, bên ngoài bất kỳ bối cảnh cụ thể nào của ứng dụng (đó là cách tốt nhất để kiểm tra), ping sẽ hoạt động tốt.

Bạn có tùy chọn sử dụng IP SLA giữa hai bộ định tuyến tại mỗi điểm không? Tôi không chắc chắn về cấu trúc liên kết của bạn ở đầu xa nên không chắc bạn có máy chủ ở phía bên kia hay máy chủ đó kết nối với bộ định tuyến mà theo lý thuyết có thể chạy IP SLA

Tôi chỉ muốn đề cập đến một vài điều. Độ trễ có thể phụ thuộc rất nhiều vào máy chủ của bạn. Hãy chắc chắn rằng đó là máy chủ mà bạn đang kiểm tra chứ không phải máy tính xách tay của bạn. Tùy thuộc vào hệ điều hành (Windows hoặc Linux) thời gian trễ ping của bạn có thể khác nhau. Tôi đã có kinh nghiệm khi các hệ thống Windows hiển thị độ trễ chậm hơn các hệ thống Linux trên cùng một đường dẫn mạng.

Ping như một bài kiểm tra hợp lý. Tuy nhiên, nếu bạn có thể thực hiện phiên TCP từ máy chủ đến điểm cuối của bạn trong trung tâm dữ liệu đó, bạn sẽ nhận được các số chính xác hơn mà không cần kiểm soát điểm cuối. Tôi sẽ chạy một gói chụp trong khi phiên TCP của bạn được thiết lập. Sau đó theo luồng TCP và xem thời gian delta của bạn. Sự khác biệt về thời gian giữa gói TCP ban đầu của bạn và chuỗi tiếp theo là gì? Đó là về thời gian thực loại độ trễ mà bạn đang thấy.

Bạn đang cố gắng khám phá xem mạng có hoạt động tốt hay máy chủ đang thực hiện công việc của họ không?

Độ trễ có thể là một điều buồn cười để đo lường - đặc biệt chính xác. Ping thực hiện một công việc đủ tốt cho một ý tưởng chung về mức độ trễ của mạng của bạn, nhưng khi nói đến số lượng rất thấp, nó có thể trở thành công cụ sai cho công việc. Nó cũng không làm gì cho thử nghiệm cấp cao hơn (như thời gian phản hồi của trang web).

Để đo lường hiệu suất mạng nghiêm ngặt (độ trễ / băng thông / mất / v.v.) Tôi thích thiết bị thử nghiệm của Exfo . Đây chỉ đơn giản là một sở thích và thực sự nó là thiết bị đầu tiên tôi sử dụng nên tôi chắc chắn các thiết bị cạnh tranh cũng sẽ hoạt động tốt. JDSU cũng là nhà cung cấp chính của loại thiết bị này.

Ngoài ra còn có PCHAR là một công cụ nguồn mở để đo độ trễ chính xác hơn ping. Tôi không trực tiếp sử dụng nó nhưng tôi biết những người có và thích nó.

Bài viết này cung cấp cho bạn một cái nhìn tổng quan tốt về một số điều mà ICMP Echo có thể / không thể làm tốt.