Как сохранить приложение 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-секундную задержку, а не ваш клиент.

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

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

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