Как сохранить мое приложение ASP.NET всегда «живым», и если это плохая идея, почему бы мне не сделать это?

Question

Недавно я развернул приложение ASP.NET на своем новом блестящем VPS, и хотя я доволен общим увеличением производительности, которое VPS может дать по сравнению с решением общего хостинга, я недоволен временем запуска моего приложения.

Моему веб-приложению требуется довольно много времени для запуска, когда мой клиент впервые обращается к нему.Я не запускаю его в режиме отладки (отключил его в моем web.config), и при запуске он не выполняет никакой реальной работы - у меня нет кода в обработчике событий запуска приложения, я ничего не запускаю лишние темы, ничего.Когда мой клиент впервые обращается к моему заявлению, ответ занимает добрых 15-20 секунд.Последующие вызовы занимают 1-2 секунды, если только я не подожду несколько минут, пока мое приложение закроется.Затем время запуска возвращается к 15-20 секундам.

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

Насколько я понимаю ASP.NET, IIS (в данном случае 7.0) компилирует веб-приложение при первом его запуске, а затем кэширует эти двоичные файлы до тех пор, пока веб-приложение не будет изменено.Является ли мое понимание неверным?

Итак, после этого предисловия размером с книгу, вот мои вопросы:

• Неправильно ли я понимаю компиляцию ASP.NET?Как это на самом деле работает?
• Есть ли способ заставить IIS кэшировать мои двоичные файлы или поддерживать работоспособность моего приложения на неопределенный срок?
• Если делать что-либо из моего предыдущего вопроса — плохая идея, то почему это плохая идея и что я могу сделать вместо этого, чтобы повысить производительность запуска?

Спасибо!

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

Answer 1

IIS также закрывает ваше веб-приложение через определенный период времени, в зависимости от его конфигурации.Я не очень хорошо знаком с IIS7 и с тем, как это настроить, поэтому вам, возможно, захочется провести небольшое исследование о том, как это настроить (отправная точка?).

Это плохо?Зависит от того, насколько хорош ваш код.Если у вас нет утечки памяти или ресурсов, вероятно, нет.

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

Answer 2

Насколько я понимаю ASP.NET, IIS (в данном случае 7.0) компилирует веб-приложение при первом его запуске, а затем кэширует эти двоичные файлы до тех пор, пока веб-приложение не будет изменено.Является ли мое понимание неверным?

Это верно.В частности, сборки создаются как теневые копии (не путать со службой моментальных снимков тома/функцией теневого копирования).Это позволяет вам заменять код в папке на лету, не затрагивая существующие запущенные сеансы.ASP.NET обнаружит изменение и скомпилирует новые версии в целевой каталог (обычно Temporary ASP.NET Files).Подробнее об этом процессе: Понимание динамической компиляции ASP.NET

Answer 3

Если это просто время компиляции, то зачастую наиболее эффективным подходом является посещение веб-сайта самостоятельно после переработки.Звоните через регулярные промежутки времени, чтобы убедиться, что 15-секундную задержку получаете именно вы, а не ваш клиент.

Однако я был бы удивлен, если бы это все время компиляции (в зависимости от оборудования) - у вас много статических экземпляров классов?Много ли они работают при запуске?

Либо с помощью трассировки, либо с помощью профилирования вы, вероятно, сможете довольно быстро определить, на что было потрачено время запуска.

Что касается того, почему сохранение процесса — плохая идея, я считаю, что это связано с прояснением.Независимо от того, насколько хорошо мы следим за нашими данными или насколько хорошо работает сборщик мусора, хорошая очистка выполняется путем перезапуска процесса.Такие вещи, как фрагментация, могут исчезнуть, а любые другие проблемы с ресурсами, возникающие со временем, исчезнут.Поэтому поддерживать работу серверного процесса бесконечно — плохая идея.