У меня есть веб-приложение ASP.NET (v4.0), которое установлено в виртуальном каталоге (как приложение) и размещено в собственном пуле приложений. Это повторяется для каждого экземпляра приложения (т. Е. Для каждого клиента).
Пулы приложений работают в интегрированном (не классическом) режиме, а для LoadUserProfile установлено значение true. В противном случае настройки по умолчанию.
У каждого экземпляра в настоящее время есть собственная копия кода / конфигурации и собственная папка данных (базовое чтение / запись файлов).
1 экземпляр этого приложения работает нормально (операция, используемая для сравнения, занимает ~ 4 секунды). Все остальные экземпляры работают медленно (от 10-25 секунд на ту же операцию).
Если я перемещу более медленный экземпляр в пул «самых быстрых» приложений, этот экземпляр оживает. Если я перемещаю более быстрый экземпляр в пул более медленных приложений, этот экземпляр замедляется до обхода.
Первоначально пулы приложений создавались точно так же - вручную. Позже я использовал процедуру копирования PowerShell, чтобы обеспечить точную копию более быстрого пула приложений и сохранить то же поведение. Сравнение файлов apppool.config показывает, что они идентичны, за исключением назначения виртуальных каталогов.
Насколько я могу судить, нет общих ресурсов, которые блокируются, и я проверил это, выключив пул эффективных приложений и перезапустив ... медленный по-прежнему медленный, а затем, когда я перезапускаю этот пул приложений (чтобы он загружался последнее) все еще быстрее ...
Чтобы еще больше изолировать проблему, я бы предложил запустить Wireshark (или другой анализатор пакетов по выбору) в хост-системе для двух сеансов. Я предполагаю, что каждый пул приложений имеет либо уникальный IP-адрес, либо уникальный порт.
Сначала получите базовую производительность, отфильтровав IP: порт пула быстрых приложений. Посмотрите, как выглядит трафик в приложение и из приложения в «нормальных» условиях.
Во втором запуске вам нужно будет захватить трафик из пула медленных / не отвечающих приложений. Если вся сетевая маршрутизация и тому подобное верны до коробки, вы должны увидеть повторяющиеся запросы в одном направлении, скорее всего, к приложению из другого места, НО если ваше приложение является чем-то, что делает много запросов к другому серверу, ваш трафик может быть тяжелый на выходе вместо входа.
Этот тест покажет вам, связана ли проблема с приложением или с проблемами, связанными с TCP / IP, которые приводят к тайм-ауту запросов к приложению из-за низкого / отсутствия связи.
Сопоставьте отметки времени ваших тестов с журналами событий сервера и (если применимо) журналами tracesink, и вы сможете сосредоточиться на проблеме.
Это не решение, но мы будем работать над ним;
Запустите IISRESET (в часы обслуживания) или завершите W3WP, принадлежащий пулу не отвечающих приложений
Запустить приложение
Пока он не отвечает, возьмите файл дампа W3WP, принадлежащий пулу медленных приложений. Используйте либо обозреватель процессов или диспетчер задач для создания файла дампа
Возьмите mscordacwks.dll и mscorwks.dll из-под C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.XXXXX
Заархивируйте и загрузите этот файл куда-нибудь, откуда я могу его скачать.
Когда IIS задерживается на длительные периоды времени без видимой причины, это обычно означает, что он ожидает истечения времени ожидания внешней службы. Когда это происходит, он пробует другой подход. Если на то пошло, это верно практически для всего в Windows или Linux. Первым подозреваемым в таких ситуациях для меня всегда является конфигурация разрешения сетевых имен. Он виновен, пока не будет доказан его невиновность.
Можно ли это воссоздать, если один пользователь зайдет на один из повторяющихся сайтов? Было бы хорошо знать, что делают ЦП и диски, когда вы воссоздаете время отклика от 10 до 20 секунд. Если кажется, что в течение 10-20 секунд ничего не происходит, вам следует проверить свои имена привязки и разрешение имен для связанных имен. Если ЦП или диски перегрызают, вам нужно будет выяснить, какой процесс работает слишком тяжело и почему.
Пожалуйста, опубликуйте свои выводы, мне любопытно.
PS Я бы также проверил разрешение имен и доступ ко всем службам аутентификации, которые могут быть задействованы. Например, если необходимо проконсультироваться с сервером домена, убедитесь, что первым DNS-сервером в вашем списке является DNS-сервер для домена.
Отслеживание неудачных запросов (FRT) будет вашим лучшим инструментом для отслеживания этого. Он покажет конвейер и время, необходимое для выполнения каждого шага. Это должно указывать на то, находится ли это в части asp.net или в самом конвейере IIS.
Чтобы настроить FRT, из IIS на уровне сайта создайте правило FRT с диапазоном состояния http от 200 до 999 и убедитесь, что FRT включен (это отдельный шаг от панели действий).
Затем воспроизведите проблему и просмотрите созданные файлы (% SystemDrive% \ inetpub \ logs \ FailedReqLogFiles \ w3svc {siteid}). Откройте их в Internet Explorer.