IIS: Як визначити, чи спричинений повільний час через повільне мережеве з'єднання

Згідно з http://support.microsoft.com/kb/944884 , "коли велика відповідь або великі відповіді надсилаються клієнтові через повільне мережеве з'єднання, значення поля, яке займає час, може бути більше, ніж очікувалося".

У мене ситуація, коли клієнт скаже: "Я надіслав запит на ваш веб-сервер о 10:03:24, і це зайняло 20 секунд, чому?". Я бачу це і в журналах IIS, але модуль ASP.NET сервера зафіксував це як 100 мс, а лічильники процесора та диска були низькими.

Я підозрюю, що це пов’язано з повільним підключенням до мережі. Як я можу це довести?

Оновлення:

1) Це запити веб-сервісу SOAP, тому немає вбудованої графіки, лише HTTP POST з єдиною XML-сторінкою результатів.

2) Також я це відтворив, зменшуючи швидкість мережі на стороні клієнта, і симптоми точно такі ж.

3) Проблема переривчаста, тобто той же запит, як правило, швидкий для клієнта, але періодично повільний. Я не можу відтворити це самостійно, окрім як заглушити мережу. Веб-журнал ASP.NET сервера показує його завжди швидко, але журнал IIS показує його повільно, коли клієнт каже, що це повільно.

4) У мене є лише доступ до сервера, і мені потрібно надати якомога більше інформації клієнту, щоб вони визнали, що проблема не була на сервері, і знають, які журнали / інструменти потрібно запустити на клієнті, щоб знайти першопричину.

У мене ситуація, коли клієнт скаже: "Я надіслав запит на ваш веб-сервер о 10:03:24, і це зайняло 20 секунд, чому?". Я бачу це і в журналах IIS, але модуль ASP.NET сервера зафіксував це як 100 мс, а лічильники процесора та диска були низькими.

Я підозрюю, що це пов’язано з повільним підключенням до мережі. Як я можу це довести?

Починається з пошуку крапель пакетів між браузером вашого клієнта та всіма джерелами зображень / скриптів / html для вищезгаданої веб-сторінки. Якщо ви знайдете послідовні краплі пакетів, то ви точно знаєте, що в мережі є щось, що потрібно виправити ... навіть якщо це просто перевантажена посилання. Краплі пакетів - не єдина причина повільної мережі, але це найпоширеніший джерело в моєму досвіді. Іншими джерелами можуть бути неправильно налаштований проксі-сервер або кеш-движок. На жаль, я не можу тут перерахувати всіх можливих винуватців мережі.

Однак люди часто звинувачують мережу, коли фактично питання швидкості знаходяться в межах власного контролю. Можливі пояснення:

• Припустимо, HTML для цієї сторінки написаний погано, і він завантажує необхідні сценарії в неправильному порядку, тому вся сторінка відображається повільно, хоча майже всі ресурси були на місці.
• На сторінці чекає ресурс, який просто не існує, і час очікування очікується.
• Сценарій знаходиться в повільному циклі, який блокується на деякий час
• Кеш-двигун займає тривалий час для отримання зображення
• Ваш CGI шукає щось у базі даних, а сам пошук повільний
• Ви використовуєте Google Analytics , який уповільнює ситуацію завдяки тому, як написана сторінка

Я можу продовжувати, але справа в тому, що ви повинні визначити точну причину того, чому сторінка сповільнюється сама. Можлива несправна мережа; Можливо також, що повільні показники сприяють й іншим факторам.

Для подальшого діагностування:

• Якщо сторінка добре завантажується у Firefox, то вкладка «Мережа» у Firebug - це ваш друг (натисніть F12, потім перейдіть на вкладку «Мережа» та перезавантажте сторінку). Firebug дає вам приємну схему водоспаду щодо того, як завантажується сторінка та де затримуються
• Якщо сторінка добре завантажується в Chrome, ви можете зробити щось подібне (натисніть CntlShiftI, натисніть на вкладку мережі та перезавантажте сторінку).
• Якщо сторінка підтримується лише в IE (btw, сором для ваших розробників HTML), найкраще почати завантажувати кожен з цих елементів сторінки ASP окремо, curlдоки ви не знайдете те, що виглядає занадто повільно, а потім з’ясуйте, чому саме цей елемент повільно.

BTW, приклади Chrome і Firefox використовували CGI-запит від Debian.org ; це хороший приклад затримки, яка виникає при пошуку CGI.

Якщо все інше не вдасться, ви можете дістати .pcapз дроту і пропустити його tcptrace; однак, хоча tcptraceдуже добре аналізує скидання пакетів, немає гарантій, що ви можете вирішити проблему tcptraceсамостійно. Інформацію про використання діагностики див. У цій відповідіtcptrace .

Підсумок статті 944884 kb полягає в тому, що фактичний час, необхідний для завершення відповіді, не може бути точно відображений у журналі. Саме тому в статті згадується мережевий час.

Якщо симптом є відтворюваним, я б здійснив захоплення пакетів на стороні сервера (і, бажано, також на стороні клієнта), щоб побачити фактичний час підтвердження з'єднання клієнтом.

Затримка на 20 секунд також може бути спричинена тим, що IIS повинен перезапустити файл w3wp.exe, який перейде до сну, коли він не використовується.