Почему мое веб-приложение видит латентность?

Question

У нас есть приложение ASP.Net, которое ведет себя странно под IIS6. Само приложение является простой сделкой ASP.Net 2.0 Webforms, здесь нет ничего странного (есть несколько HTTP-модулей в конвейере, но я бы не подумал об этих странных :)). То, что я не понимаю, - это время выполнения страницы, или, точнее, разница между временем, сообщенным трассировкой ASP.Net (trace.axd) и наблюдаемым клиентом (Fiddler). Когда приложение запускается на поле разработчика (WinXP, IIS5.1), времена сообщенные ASP.Net и Скрипач очень близки:

Page exec time    : 0.0919834 
Fiddler Total Sequence time: 0.1560980

Я могу понять, 60мс тратятся получать 5KB ценность данных от IIS для Fiddler (оба из которых работают на одной машине, BTW). Теперь, когда мы переместим код сервера (Win2k3, IIS6), картина резко меняется:

Page exec time    : 0.1702014 
Fiddler Total Sequence time: 0.5156283

Это та же страница, и Скрипач снова работает на той же машине с кодом. Почему вдруг требуется 350 мс для доставки того же 5 КБ?

PS. На обеих машинах результаты получаются путем обращения к URL-адресу с помощью имени хоста машины, например. http://machinename/app/page.aspx (в отличие от http://localhost/app/page.aspx).

PPS. Конфигурирование, настройки окна разработчика и сервера находятся как можно ближе к ним - оба используют тот же самый web.config. Оба попадают в DB (сервер sql) со встроенным auth, и, следовательно, приложение работает под учетной записью домена. Приложение использует проверку подлинности форм и НЕ выступает в роли олицетворения (т. Е. Всегда работает под одной учетной записью). Теперь, как это работает на IIS5, отличается от IIS6 - на IIS5 учетная запись указана в теге в machine.config, а в IIS6 это параметр AppPool. Настройка кажется довольно типичной для обеих сред, и я не могу себе представить, что она вызывает задержки в 350 мс ...

Answer 1

После израсходования одного из нескольких незначительных инцидентов поддержки, которые мы получили с нашей подпиской MSDN, я, наконец, знаю правильный ответ на вопрос «Где все это время потрачено». Короче говоря, время тратится на модули HTTP, которые мы имеем в нашем конвейере. Измерения времени, о которых сообщает ASP.Net trace.axd, записывают только время, проведенное на самой странице .aspx, модули: NOT.

Один простой способ убедиться в этом (и посмотреть, как долго каждый модуль выполняет свою задачу) - использовать ETW (трассировка событий для Windows). Вот explanation (я сильно подозреваю, что этот пост был написан после того, как они посмотрели на наш случай :)). Одна вещь, которую я могу добавить к превосходному описанию выше, это то, что я использовал SvcTraceViewer вместо LogParser для анализа вывода трассировки.

Обновление: вышеупомянутый подход также работает на Windows Server 2008, просто убедитесь, что у вас есть Tracing installed.

Answer 2

Проведите маршрут трассировки по URL-адресу, который вы вызываете, и сравните их. Я держу пари с машиной разработчика, которую вы остаёте на внутренней стороне машины, но на производственной машине вы выходите наружу, а затем возвращаетесь через IP-адрес.

Если это так попробуйте добавить это в файл хостов (C: \ WINDOWS \ system32 \ Drivers \ Etc \ хостов

www.mysite.com 127.0.0.1 

Это сделает ваш запрос не выходить за пределы машины чтобы сделать запрос. Вы должны увидеть время отклика, чтобы начать приходить в соответствие друг с другом.

Update

Учитывая новые обновления. Если сервер находится под нагрузкой, при тестировании на производстве й может объяснять разницу, поскольку он активно пытается доставить больше запросов, чем машина разработки, которая пытается только доставить 1.

Возможно, это связано с тем, что вы тестируете две разные версии IIS, 5.1 на XP и 6.0 на 2003. Действительно не удается объяснить различия, если обе среды не работают с одним и тем же программным обеспечением.

Answer 3

Является ли приложение, работающее с одинаковыми версиями релизов на обеих коробках?

EDIT: Конвейер запросов сильно изменился между IIS5 и IIS6, trace.axd только увидит часть ASP.NET, а не новый пул приложений и компоненты HTTP.Sys.

Я бы предположил, что конфигурация может быть настроена на IIS6 немного, но вы, вероятно, смотрите на разницу между легким непродуктивным веб-сервером (IIS5) и надежным веб-сервером с отдельными пулами приложений для управления и более уровнями абстракции ,