IIS: Làm thế nào để biết nếu thời gian chậm là do kết nối mạng chậm

Theo http://support.microsoft.com/kb/944884 , "khi một phản hồi lớn hoặc phản hồi lớn được gửi đến máy khách qua kết nối mạng chậm, giá trị của trường mất thời gian có thể nhiều hơn mong đợi".

Tôi có một tình huống mà một khách hàng sẽ nói: "Tôi đã gửi yêu cầu đến máy chủ web của bạn lúc 10:03:24 và mất 20 giây, tại sao?". Tôi cũng có thể thấy điều này trong các bản ghi IIS, nhưng mô-đun ASP.NET của máy chủ đã ghi lại nó dưới dạng 100ms, và bộ đếm CPU và Đĩa thấp.

Tôi nghi ngờ rằng đó là do kết nối mạng chậm. Làm thế nào tôi có thể chứng minh điều này?

Cập nhật:

1) Đây là các yêu cầu Dịch vụ Web SOAP, do đó không có đồ họa nhúng, chỉ là một POST HTTP với một trang kết quả XML duy nhất.

2) Ngoài ra, tôi đã tái tạo điều này bằng cách điều chỉnh tốc độ mạng ở phía máy khách và các triệu chứng hoàn toàn giống nhau.

3) Vấn đề không liên tục, có nghĩa là cùng một yêu cầu thường nhanh đối với khách hàng nhưng đôi khi chậm. Tôi không thể tự tái tạo điều này ngoài việc điều chỉnh mạng. Ghi nhật ký ASP.NET của máy chủ cho thấy nó luôn nhanh, nhưng đăng nhập IIS cho thấy nó chậm khi máy khách nói rằng nó chậm.

4) Tôi chỉ có quyền truy cập vào máy chủ và cần cung cấp càng nhiều thông tin càng tốt cho khách hàng để họ chấp nhận rằng vấn đề không nằm ở máy chủ và biết đăng nhập / công cụ nào để chạy trên máy khách để tìm nguyên nhân gốc.

Tôi có một tình huống mà một khách hàng sẽ nói: "Tôi đã gửi yêu cầu đến máy chủ web của bạn lúc 10:03:24 và mất 20 giây, tại sao?". Tôi cũng có thể thấy điều này trong các bản ghi IIS, nhưng mô-đun ASP.NET của máy chủ đã ghi lại nó dưới dạng 100ms, và bộ đếm CPU và Đĩa thấp.

Tôi nghi ngờ rằng đó là do kết nối mạng chậm. Làm thế nào tôi có thể chứng minh điều này?

Nó bắt đầu bằng việc tìm kiếm các gói giảm giữa trình duyệt của khách hàng của bạn và tất cả các nguồn hình ảnh / script / html cho trang web nói trên. Nếu bạn tìm thấy các gói tin nhất quán, thì bạn biết chắc chắn có một cái gì đó trong mạng cần được sửa chữa ... ngay cả khi đó chỉ là một liên kết bị quá tải. Giọt gói không phải là lý do duy nhất cho một mạng chậm, nhưng đó là nguồn phổ biến nhất trong kinh nghiệm của tôi. Các nguồn khác có thể là một proxy hoặc bộ máy cache được định cấu hình sai. Đáng buồn thay, tôi không thể liệt kê tất cả các thủ phạm mạng có thể có ở đây.

Tuy nhiên, mọi người thường đổ lỗi cho mạng, trong thực tế, các vấn đề về tốc độ nằm trong tầm kiểm soát của chính họ. Giải thích có thể:

• Giả sử HTML cho trang đó được viết kém và nó tải các tập lệnh được yêu cầu theo thứ tự sai để toàn bộ trang hiển thị chậm, mặc dù hầu hết tất cả các tài nguyên đều được đặt đúng chỗ.
• Trang đang chờ một tài nguyên đơn giản là không tồn tại và hết thời gian trong khi chờ đợi.
• Một tập lệnh nằm trong một vòng lặp chậm, chặn một lúc
• Một công cụ bộ đệm mất nhiều thời gian để cung cấp một hình ảnh
• CGI của bạn đang tìm kiếm thứ gì đó trong cơ sở dữ liệu và bản thân việc tra cứu bị chậm
• Bạn đang sử dụng Google Analytics , làm chậm mọi thứ do cách viết trang

Tôi có thể tiếp tục, nhưng vấn đề là bạn phải tìm ra lý do chính xác cho lý do tại sao trang bị chậm. Một mạng lưới thiếu sót là có thể; cũng có thể các yếu tố khác đang góp phần vào hiệu suất chậm.

Để chẩn đoán thêm:

• Nếu trang tải tốt trong Firefox, thì tab Mạng trong Fireorms là bạn của bạn (Lượt truy cập F12, sau đó chuyển đến tab Mạng và tải lại trang). Firebug cung cấp cho bạn một sơ đồ thác nước đẹp để biết cách tải trang và nơi trì hoãn
• Nếu trang tải tốt trong Chrome, bạn có thể làm điều gì đó tương tự (Nhấn CntlShiftI, nhấp vào tab mạng và tải lại trang).
• Nếu trang chỉ được hỗ trợ trong IE (btw, xấu hổ cho các nhà phát triển HTML của bạn), thì cách tốt nhất của bạn là bắt đầu tải từng phần tử trang ASP này curlcho đến khi bạn tìm thấy thứ gì đó quá chậm, sau đó tìm hiểu tại sao phần tử cụ thể đó chậm

BTW, các ví dụ về Chrome và Firefox đã sử dụng truy vấn CGI từ Debian.org ; đây là một ví dụ tốt về sự chậm trễ xuất phát từ việc tra cứu CGI.

Khi tất cả những thứ khác không thành công, bạn có thể nhận được .pcaptừ wireshark và chạy qua tcptrace; tuy nhiên, trong khi tcptracerất tốt trong việc phân tích các bãi chứa gói, không có gì đảm bảo rằng bạn có thể cô lập vấn đề tcptracemột mình. Xem câu trả lời này để biết thông tin về việc sử dụng tcptracechẩn đoán.

Kết quả cuối cùng của bài viết kb 944884 là thời gian thực tế cần thiết để hoàn thành phản hồi có thể không được phản ánh chính xác trong nhật ký. Đó là lý do tại sao bài viết đề cập đến thời gian mạng.

Nếu triệu chứng có thể lặp lại, tôi sẽ thực hiện chụp gói ở phía máy chủ (và tốt nhất là phía máy khách) để xem thời gian thực tế mà kết nối được máy khách thừa nhận.

Độ trễ 20 giây cũng có thể là do IIS phải khởi động lại w3wp.exe, nó sẽ chuyển sang chế độ ngủ khi không sử dụng.