Медленное первое посещение при предварительно скомпилированном просмотре - PullRequest
0 голосов
/ 08 июня 2018

Я предварительно скомпилировал свое приложение: Настройки прекомпиляции , также установил настройки компиляции на

<compilation targetFramework="4.6.2"
             batch="false"
             debug="false"
             optimizeCompilations="true">
</compilation>

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

Я использовал профилировщики, чтобы проверить, является ли это наш код или нет, ноэто выполняется быстро.При первом посещении страницы задержка составляет около 20 секунд (иногда даже до 60 секунд).Профилировщик показывает это (ответ на первое посещение страницы возвращается с задержкой), даже если представление предварительно скомпилировано (обратите внимание на 20-секундную задержку после последнего запроса и ответа SQL): результат профилировщика при первом запросе .

Ответ на каждый следующий запрос страницы возвращается немедленно: Результат профилировщика при втором запросе .

Я проверил инициализацию ORM, попытался минимизировать js / css, gzip их и проверитьлюбой другой известный вариант, но безрезультатно.Каждое представление / страница по первому запросу возвращается медленно, хотя приложение и пул приложений нагреваются.

Затем я включил трассировку в IIS и обнаружил следующее: задержка после события HANDLER_CHANGED

Задержка происходит после смены обработчика.Теперь ... странная, я полагаю, вещь меняется с OldHandlerName, который является нулевым.Может ли это быть причиной?Или может быть что-то с событием, которое происходит после задержки (HttpCacheModule)?Я нашел несколько других подобных выводов, связанных с медленными начальными запросами страниц, но ни на один из них не был дан правильный ответ.Один из этих ответов можно найти здесь , но изменение outputCache не помогло.Мои настройки outputCache:

<caching>
    <outputCacheSettings>
         <!--outputCacheSettings - Controls how controller actions cache content in one central location.
                           You can also modify the web configuration file without recompiling your application.--> 
        <outputCacheProfiles>
             <!--Cache the 400 Bad Request route for a day.--> 
            <add name="BadRequest" duration="86400" location="Server" varyByParam="none" />
             <!--Cache the 403 Forbidden route for a day.--> 
            <add name="Forbidden" duration="86400" location="Server" varyByParam="none" />
             <!--Cache the 405 Method Not Allowed route for a day.--> 
            <add name="MethodNotAllowed" duration="86400" location="Server" varyByParam="none" />
             <!--Cache the 404 Not Found route for a day.--> 
            <add name="NotFound" duration="86400" location="Server" varyByParam="none" />
             <!--Cache the 401 Unauthorized route for a day.--> 
            <add name="Unauthorized" duration="86400" location="Server" varyByParam="none" />
             <!--Cache the 500 Internal Server Error route for a day.--> 
            <add name="InternalServerError" duration="86400" location="Server" varyByParam="none" />
        </outputCacheProfiles>
    </outputCacheSettings>
</caching>

Я бью стену здесь ... есть идеи?

: РЕДАКТИРОВАТЬ: После дальнейшего анализа оказывается, что даже после запуска прекомпиляции,

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files 

не заполнен dll при развертывании.Когда я запускаю

aspnet_compiler -v /virtual_path

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

Итак ... похоже, IIS понятия не имеет, что эти библиотеки уже предварительно скомпилированы и готовы к действию.Вы знаете, как сделать это известным для этого?Можем ли мы вообще отключить Временные файлы ASP.NET и заставить его использовать только папки bin наших приложений?

: EDIT2: я вижу, что в IIS Pages and Controls есть опция, называемая Compilation Mode, и она "Всегда "по умолчанию (что означает, что в любом случае он вызывает компиляцию), но, как упоминалось в msdn, эти параметры применяются только к веб-формам ASP.NET.Должна быть где-то похожая настройка для MVC.Помогите!: -)

1 Ответ

0 голосов
/ 08 июня 2018

Прекомпиляция не делает все, о чем вы думаете.Он компилируется в dll, но затем dll необходимо преобразовать из IL в машинный код.Это происходит, когда вы раскручиваете приложение в IIS.Если вы работаете на WIndows Server 2012 или более поздней версии, в пуле приложений можно настроить функции, которые помогут ему оставаться горячим после загрузки в режиме запуска Always Running.

Вы можете найти этот параметр, открывменеджер IIS |Пулы приложений |выберите соответствующий пул приложений |Расширенные настройки и установите режим запуска «Всегда запущен».

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

...