циклический пул приложений IIS вызывает медленный опыт первого пользователя

Question

Когда я перезапускаю пул приложений для своего веб-приложения через IIS MMC, первый пользователь, который запросит страницу в веб-приложении, будет получать очень медленный ответ от сайта. После этого первоначального запроса каждая страница там после в порядке. Пользователь также может выйти с сайта, вернуться позже и скорость будет быстрой. Я обеспокоен первой, начальной загрузкой сайта. Если бы я должен был написать скрипт для перезапуска пула приложений в 3 часа ночи, что еще я могу сделать для

a.) Выдавать себя за пользователя, посещающего сайт и получающего первоначальную медленную загрузку, что делает приложение «готовым» для пользователей утром.

или

b.) Скажите пулу приложений, что нужно спулингировать память и тому подобное, и пользователю не нужно запускать этот процесс.

Answer 1

Во-первых, вам не нужен скрипт для перезапуска приложения в 3 часа ночи. У пулов приложений есть настройки, которые можно выбрать при перезапуске. По умолчанию я думаю, что они перезагружаются каждые 29 часов, что является странным параметром, и я рекомендую изменить его. В противном случае вы будете получать звонки с требованием потерянных сеансов в случайное время дня.

Я должен предположить, что у вас есть приложение ASP.NET в рассматриваемом пуле приложений. При первом запросе задержка в основном связана с тем, что рабочему процессу ASP.NET необходимо скомпилировать веб-сайт и / или загрузить библиотеки DLL, необходимые во время выполнения. Чтобы решить эту проблему, большинство используют задачу поддержания активности, которая может регулярно отправлять запросы на сайт, чтобы убедиться, что он полностью загружен. Предложение Мэтта также является хорошим, но оно решит проблему только тогда, когда вы самостоятельно перерабатываете пул приложений. Пулы приложений могут перерабатывать самостоятельно по любому ряду других причин, и средства поддержки будут поддерживать загруженные объекты большую часть времени.

Answer 2

Это старый вопрос, но у меня был какой-то недавний опыт с этим, и я решил опубликовать его. В зависимости от ситуации вы можете сделать несколько вещей.

Причина, по которой он медленен, заключается в том, что рабочий процесс IIS переходит в спящий режим после определенного периода времени. Настройка для этого называется Idle Timeout и может быть установлена ​​в 0, если вы хотите отключить эту функцию. Но я бы исследовал это, прежде чем вносить подобные изменения.

Кроме того, когда IIS запускается, он регистрирует библиотеки DLL в вашей корзине. Если у вас небольшой сайт, вероятно, не так уж много DLL (кроме стандартных .NET DLL). Если у вас много (, возможно, несколько неиспользованных ) DLL, они все равно должны быть обработаны. Если вы удалите старые библиотеки DLL / Code , IIS больше не будет тратить время на их обработку и будет быстрее перезагружаться.

У нас есть сайт DotNetNuke, в котором было около 35 «устаревших» модулей, которые больше не использовались, но все еще находились в папке / bin. Мы удалили модули и библиотеки DLL из / bin, и время перезапуска сайта сократилось вдвое.

Еще одна вещь. Вы можете настроить страницу Keep Alive , которая периодически загружается, чтобы сайт не закрывался. Я знаю, что наш хостинг-провайдер предлагает эту услугу. У нас есть простая ASPX-страница на сайте, которую они посещают каждые 30 минут, чтобы убедиться, что сайт остается загруженным в память.

Answer 3

У меня возникла похожая проблема. При первой загрузке JIT-компилятору необходимо преобразовать MSIL в машинный код. Обычно это делается очень быстро и выполняется из теневой копии папки «Temporary ASP.NET Files», если приложение используется не впервые. Сборки вашего приложения копируются здесь при первой загрузке приложения, так что DLL-библиотеки приложений могут быть оперативно заменены в реальном месте без ошибок типа «в использовании».

Я отвлекся, JIT-компилятор компилирует сборки по мере необходимости, что обычно довольно быстро. Это меняется, когда вы используете подписанные сборки и пользователь, выполняющий JIT-компиляцию (т. Е. Пользователь пула приложений), не имеет доступа к Интернету. В этом случае он просто будет сидеть там около 10-20 секунд, пока он попытается проверить подпись в Интернете, до которой он не сможет добраться.

Когда у нас возникла эта проблема, мы использовали сборки Enterprise Library, поэтому вместо того, чтобы время JIT-компиляции занимало несколько секунд после перезапуска пула приложений, в некоторых случаях оно занимало более минуты, так как ожидалось время ожидания для интернет-запросов на проверку подписи.

Так что либо отключите проверку подписи на ваших сборках во время JIT (параметр конфигурации), либо предоставьте пользователю пула приложений доступ в Интернет.

Answer 4

Все происходит при первой загрузке сайта. Единственное, что вы можете сделать, это смоделировать запрос на сайте после переработки. Это можно сделать с помощью простого приложения. Самый простой способ сделать это в .NET - использовать класс HttpWebRequest .