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

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

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

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

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

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

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

Спасибо!

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


asp.net performance iis-7
person Rob    schedule 03.05.2009    source источник
comment
Я собирался предложить точно такой же подход, как предлагали ответившие на другой аналогичный вопрос. Вы уверены, что ответы на этот вопрос не соответствуют вашим потребностям? Думаю, они хорошо объясняют ситуацию.   -  person DOK    schedule 03.05.2009
comment
@DOK, спасибо за ваш отзыв, другой вопрос был хорош в том, что касается моего вопроса, но я думаю, что мой вопрос охватывает больше того, почему и лучшие практики этой проблемы.   -  person Rob    schedule 03.05.2009
comment
Я думаю, что алгоритм поиска, используемый в SO, действительно плохой - отсюда и дубликаты.   -  person Joe Phillips    schedule 03.05.2009

Ответы (3)


arrow_upward
4
arrow_downward

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

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

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

person Community    schedule 03.05.2009
comment
Как обсуждалось выше, вам необходимо установить «Тайм-аут простоя» в IIS, чтобы приложение не удалялось из памяти слишком рано (по-моему, по умолчанию 20 минут). Это в дополнение к предварительной компиляции, максимальное значение ограничивается временем повторного цикла пула приложений, а также собственным пределом. Пулы приложений ›[Используемый пул]› Расширенные настройки ›Тайм-аут простоя - person rjarmstrong; 05.07.2013

arrow_upward
2
arrow_downward

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

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

person Sören Kuklau    schedule 03.05.2009

arrow_upward
1
arrow_downward

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

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

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

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

person Tollo    schedule 03.05.2009