Предварительно скомпилированный ASP.NET, но все еще медленный запуск?

Я пытаюсь понять, что я делаю неправильно или не понимаю. У меня есть решение с веб-приложением и несколькими библиотеками классов.

Я отредактировал настройки публикации веб-приложения веб-проекта. Он имеет флажок «предварительно скомпилировать это приложение перед публикацией», и я выбрал «Только файлы, необходимые для запуска этого приложения».

Я создал профиль публикации, который просто сбрасывает его в папку. Из этой папки я загружаю (используя FTP) библиотеки DLL на промежуточный сайт, который я настроил, где я провожу окончательное тестирование перед развертыванием приложения вживую. После загрузки DLL и перехода на промежуточный сайт все еще существует задержка запуска приложения, которая кажется такой же медленной. Разве это не должно быть устранено предварительной компиляцией?

Изменить: отключение возможности обновления сайта устраняет проблему. Разрешение на его обновление приводит к тому, что все мои страницы ASPX и пользовательские элементы управления компилируются при просмотре первой страницы, что приводит к задержке, даже если код компилируется. Я отключил пакетную компиляцию и включил оптимизацию компиляции в файле web.config, и теперь она работает быстро:

<compilation batch="false" optimizeCompilations="true" />

asp.net precompile
person GregInWI2    schedule 03.03.2013    source источник
comment
Есть шанс, что для параметра debug установлено значение true?   -  person Zdeslav Vojkovic    schedule 03.03.2013
comment
Пожалуйста, определите медленно. Когда вы копируете приложения, это может привести к перезапуску приложения. Это также зависит от того, что делают приложения (например, загружают ресурсы из БД, файлы и т. д. и т. д.).   -  person Joseph Lee    schedule 03.03.2013
comment
Это была отладка в публикации, поэтому я изменил ее на выпуск. Я очистил каталог bin на сервере, чтобы избавиться от всего, что не используется, и повторно загрузил новые библиотеки DLL. Все еще медленно (10+ секунд для ответа сайта).   -  person GregInWI2    schedule 03.03.2013
comment
Первый раз или каждый раз? Если это только в первый раз, то это может быть не ваш код. Но если это каждый раз; тогда это может быть ваш код; или может быть вашей сети.   -  person Joseph Lee    schedule 03.03.2013
comment
Каждый раз, когда я загружаю DLL, для ответа требуется 10 или более секунд. Использование сайта быстрое, только начальное время запуска медленное. Если я загружу библиотеки DLL, зайду на сайт, снова загружу библиотеки DLL, ждать не придется. Но они не изменены. Я думаю, что предварительная компиляция не должна работать.   -  person GregInWI2    schedule 03.03.2013
comment
Если я сниму флажок Разрешить загрузку предварительно скомпилированного сайта, он будет быстрым, в противном случае - медленным. Я хочу, чтобы это было проверено :(   -  person GregInWI2    schedule 03.03.2013
comment
Ой! В этом случае вам поможет Multicore JIT! Ссылка: blogs.msdn.com/b/dotnet/archive/2012/10/18/   -  person Joseph Lee    schedule 04.03.2013
comment
Это определенно нечто большее, чем просто строка web.config. Мой исходный проект, о котором это было опубликовано, не имеет предварительной компиляции, выбранной в настройках публикации, и это очень большой сайт. Никаких задержек, когда я выкладываю новые библиотеки DLL. Теперь у меня новый сервер и новый сайт, и каждый раз у меня длинный 5+ секундный удар даже с этой строкой. Должна быть какая-то комбинация вещей, чтобы избавиться от задержки, но я пока не знаю, что это такое. Возможно, задержка перезапуска пула приложений. Я отпишусь, когда узнаю, что нужно сделать, чтобы избавиться от задержки.   -  person GregInWI2    schedule 13.02.2014

Ответы (4)


arrow_upward
3
arrow_downward

Может быть, вы оставили настройку debug=True в конфигурации?

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

См. здесь и здесь Больше подробностей.

person Zdeslav Vojkovic    schedule 03.03.2013
comment
На сервере в web.config было установлено значение debug=true, поэтому я удалил его. Не помогло. Также на моей машине разработки развертывание было настроено на отладку, поэтому я изменил его на выпуск, но это тоже не помогло. Хотя он определенно скомпилировался в релизе. - person GregInWI2; 03.03.2013

arrow_upward
0
arrow_downward

Какая у вас версия фреймворка? Если вы используете .Net 3.5 (в частности), вам следует рассмотреть возможность использования:

<configuration>
    <runtime>
        <generatePublisherEvidence enabled="false"/>
    </runtime>
</configuration>

Это примерно вдвое меньше времени холодного пуска. Но известная проблема заключается в том, что когда IIS выполняет холодный запуск приложения, возникает начальная задержка. Это не ограничивается развертыванием приложения, но также и повторным использованием пула приложений.

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

person Joseph Lee    schedule 03.03.2013
comment
У меня уже есть это в моем web.config. Я использую сайт, затем загружаю новые библиотеки DLL, а затем жду ответа более 10 секунд. Сценарий для попадания на сайт не поможет. Вот почему я думал, что предварительная компиляция должна помочь. Но ничего не изменилось. - person GregInWI2; 03.03.2013
comment
К сожалению, у меня нет решения для этого. Это известная проблема. Существует разница между временем запуска IIS и временем компиляции. Даже если вы устраните время компиляции (с помощью предварительной компиляции), мы все равно застрянем на времени запуска. - person Joseph Lee; 04.03.2013
comment
Это не время запуска. Если я компилирую все, это почти мгновенно. Когда я проверяю Разрешить загрузку предварительно скомпилированного сайта, он работает медленно. Приходится все перекомпилировать. - person GregInWI2; 04.03.2013
comment
О, в таком случае Multicore JIT сможет вам помочь! Ссылка: blogs.msdn.com/b/dotnet/archive/2012/10/18/ И эта ссылка также поможет с автоматическим запуском: weblogs.asp.net /scottgu/archive/15.09.2009/ - person Joseph Lee; 04.03.2013

arrow_upward
0
arrow_downward

Мне удалось разобраться со своим. Раньше мой холодный запуск занимал 18 минут на моей локальной машине разработки (при подготовке это было меньше 30 секунд).

Наконец-то я заметил, что во время холодного перезапуска программа загружала процессор. Программа была.. MsMpEng.exe - Это Microsoft Security Essentials включая Microsoft Defender. Я удалил его, и теперь мой сайт загружается менее чем за 30 секунд.

Очевидно, он сканировал каждую .dll, копируемую во время холодного запуска, и блокировал копирование каждой дополнительной .dll до тех пор, пока не было завершено сканирование предыдущей.

Холодный пуск теперь меньше 30 с.

person Glennweb    schedule 29.01.2015

arrow_upward
0
arrow_downward

В нашем случае предварительно скомпилированное приложение (которое ранее было обновлено в мгновение ока) начало работать медленно после того, как мы добавили SignalR.

Теперь я профилировал процесс, используя этот инструмент с открытым исходным кодом (отказ от ответственности, я являюсь участником проект, изначально написанный командой Stackoverflow), и я видел это среди самых длинных стеков вызовов:

//...skipped
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start
Microsoft.Owin.Host.SystemWeb.OwinCallContext.AcceptCallback
//...skipped

Спасибо, Обама.

Что за Майкрософт?

Поздоровайся с зависимостью Овина.

person Alex from Jitbit    schedule 20.06.2017