IIS: Jak stwierdzić, czy wolne działanie jest spowodowane wolnym połączeniem sieciowym

Według http://support.microsoft.com/kb/944884 „gdy duża odpowiedź lub duże odpowiedzi są wysyłane do klienta przez wolne połączenie sieciowe, wartość zajętego pola może być większa niż oczekiwano”.

Mam sytuację, w której klient powie: „Wysłałem żądanie na Twój serwer internetowy o 10:03:24 i zajęło to 20 sekund, dlaczego?”. Widzę to również w dziennikach IIS, ale moduł serwera ASP.NET serwera zarejestrował go jako zajmujący 100 ms, a liczniki procesorów i dysków były niskie.

Podejrzewam, że wynika to z wolnego połączenia sieciowego. Jak mogę to udowodnić?

Aktualizacja:

1) Są to żądania SOAP Web Service, dlatego nie ma osadzonej grafiki, tylko HTTP POST z pojedynczą stroną wyników XML.

2) Powtórzyłem to, ograniczając prędkość sieci po stronie klienta, a objawy są dokładnie takie same.

3) Problem jest sporadyczny, co oznacza, że ​​to samo żądanie jest zwykle szybkie dla klienta, ale czasami powolne. Nie mogę tego odtworzyć inaczej niż poprzez dławienie sieci. Rejestrowanie ASP.NET na serwerze pokazuje, że zawsze jest szybkie, ale rejestrowanie w IIS pokazuje, że jest powolne, gdy klient mówi, że jest powolne.

4) Mam tylko dostęp do serwera i muszę podać jak najwięcej informacji klientowi, aby zaakceptowali, że problem nie występował na serwerze, i wiedzą, jakie rejestrowanie / narzędzia uruchomić na kliencie, aby znaleźć główną przyczynę.

Mam sytuację, w której klient powie: „Wysłałem żądanie na Twój serwer internetowy o 10:03:24 i zajęło to 20 sekund, dlaczego?”. Widzę to również w dziennikach IIS, ale moduł serwera ASP.NET serwera zarejestrował go jako zajmujący 100 ms, a liczniki procesorów i dysków były niskie.

Podejrzewam, że wynika to z wolnego połączenia sieciowego. Jak mogę to udowodnić?

Zaczyna się od szukania zrzutów pakietów między przeglądarką klienta a wszystkimi źródłami obrazów / skryptów / HTML dla wyżej wymienionej strony internetowej. Jeśli znajdziesz spójne spadki pakietów, to na pewno wiesz, że w sieci jest coś, co należy naprawić ... nawet jeśli jest to przeciążone łącze. Upuszczanie pakietów nie jest jedynym powodem powolnej sieci, ale jest to najczęstsze źródło w moim doświadczeniu. Innymi źródłami mogą być źle skonfigurowany serwer proxy lub silnik pamięci podręcznej. Niestety nie mogę tutaj wymienić wszystkich możliwych sprawców sieci.

Jednak ludzie często obwiniają sieć, gdy w rzeczywistości problemy z prędkością są w ich gestii. Możliwe wyjaśnienia:

• Załóżmy, że kod HTML tej strony został źle napisany i ładuje wymagane skrypty w niewłaściwej kolejności, dzięki czemu cała strona renderuje się powoli, mimo że prawie wszystkie zasoby były na miejscu.
• Strona czeka na zasób, który po prostu nie istnieje i upłynął limit czasu oczekiwania.
• Skrypt znajduje się w wolnej pętli, która blokuje się na chwilę
• Mechanizm pamięci podręcznej długo zajmuje dostarczenie obrazu
• Twój CGI szuka czegoś w bazie danych, a samo wyszukiwanie jest powolne
• Używasz Google Analytics , który spowalnia pracę ze względu na sposób pisania strony

Mógłbym kontynuować, ale chodzi o to, że musisz ustalić dokładny powód, dla którego strona jest wolna. Wadliwa sieć jest możliwa; możliwe jest również, że inne czynniki przyczyniają się do niskiej wydajności.

Aby dalej diagnozować:

• Jeśli strona ładuje się dobrze w Firefoksie, to karta Sieć w Firebug jest twoim przyjacielem (Hit F12, a następnie przejdź do karty Sieć i ponownie załaduj stronę). Firebug daje ładny schemat wodospadu pokazujący, w jaki sposób strona się ładuje i gdzie są opóźnienia
• Jeśli strona ładuje się dobrze w Chrome, możesz zrobić coś podobnego ( CntlShiftInaciśnij, kliknij kartę sieci i załaduj stronę ponownie).
• Jeśli strona jest obsługiwana tylko w przeglądarce IE (btw, wstyd dla programistów HTML), najlepiej jest zacząć ładować każdy z tych elementów strony ASP osobno, curldopóki nie znajdziesz czegoś, co wygląda o wiele za wolno, a następnie dowiedz się, dlaczego ten konkretny element jest wolny.

BTW, przykłady Chrome i Firefox wykorzystały zapytanie CGI z Debian.org ; jest to dobry przykład opóźnienia wynikającego z wyszukiwania CGI.

Kiedy wszystko inne zawiedzie, możesz uzyskać .pcapod wireshark i uruchomić go tcptrace; jednak, chociaż tcptracejest bardzo dobry w analizie zrzutów pakietów, nie ma gwarancji, że można odizolować problem tcptracesamodzielnie. Zobacz tę odpowiedź, aby uzyskać informacje na temat korzystania z tcptracediagnostyki.

Rezultatem artykułu 944884 kb jest to, że faktyczny czas wymagany do ukończenia odpowiedzi może nie zostać dokładnie odzwierciedlony w dzienniku. Dlatego w artykule wspomniano o czasie w sieci.

Jeśli objaw jest odtwarzalny, wykonałbym przechwytywanie pakietów po stronie serwera (a najlepiej także po stronie klienta), aby zobaczyć rzeczywiste czasy, kiedy klient potwierdził połączenie.

20 sekundowe opóźnienie może być również spowodowane ponownym uruchomieniem przez IIS pliku w3wp.exe, który przejdzie w tryb uśpienia, gdy nie będzie używany.