Веб-приложение Azure (ASP.NET MVC) становится холодным каждые десять минут и занимает +10-20 секунд для загрузки

У меня есть несколько возможных ответов.

Entity framework code-first / инициализация базы данных: Если вы используете code first setup с миграциями и, возможно, начальными данными, каждая из этих вещей может вызвать некоторые проблемы "прогрева".

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

Версия фреймворка сущности: Entity framework сама по себе также имела много улучшения производительности в 5 и 6.x некоторые из них также имеют отношение как к холодным, так и к теплым скоростям запуска.

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

Recycle Похоже, что вы испытываете эти проблемы, когда приложение повторяет, и это разве автоматическая инициализация (именно поэтому вы получаете этот холодный удар) худшие проблемы производительности, которые я видел с этими вещами, обычно связаны с entity framework и precompile. Но и то и другое можно легко исправить. Но обеспечение того, что приложение "всегда работает" и самоинициализируется после рециркуляции, также гарантирует, что пользователи не получат этого холодного удара.

Обновление: Поскольку это было связано с видом, я могу предложить решение, которое я нашел очень полезным. Установка RazorGenerator.Пакет MVC Nuget. И добавление этого двигателя в качестве первого движка вы будете использовать скомпилированные представления.

В App_Start можно создать файл под названием RazorGeneratorMvcStart.cs с таким содержимым:

using RazorGenerator.Mvc;

[assembly: WebActivatorEx.PostApplicationStartMethod(typeof(MyNamespace.RazorGeneratorMvcStart), "Start")]

namespace MyNamespace {
    public static class RazorGeneratorMvcStart {
        public static void Start() {
            ViewEngines.Engines.Insert(0, new PrecompiledMvcEngine(typeof(RazorGeneratorMvcStart).Assembly));

            VirtualPathFactoryManager.RegisterVirtualPathFactory(engine);
        }
    }
}

Движок razor может даже взять параметр для UsePhysicalViewsIfNewer для тех, кто любит заменять вид в реальном времени. В этом случае он использует предварительно скомпилированную версию, если только представление с более новой датой, чем скомпилированная .библиотека dll была помещена в папку.

Этот подход должен решить проблемы производительности с представлениями.

Несколько идей:

1. В колонке веб-приложения перейдите в меню диагностика и решение проблем. Затем нажмите на счетчики производительности. Я бы честно прошерстил каждый из доступных счетчиков perf, обращая внимание на временную шкалу против вашей ухудшенной производительности. Однажды я узнал, что SignalR душит мой сервер из-за неуправляемых соединений, посмотрев на счетчик потоков.

2. Является ли журнал ошибок сервера в Application Insights чистым?

3. Под днищем Экран диагностики и решения проблем, вы видите что-нибудь подозрительное в журналах трассировки неудачных запросов?

1. Отделите что-либо от развертывания против локального. Если приложение работает идеально в локальной среде, то при переходе в Azure происходит что-то другое. Разрешение чего-то требует много времени.
2. любой статический ресурс (скрипт, стили и т. д.) автоматически кэшируется браузером по первому запросу, поэтому при последующем запросе проблема не должна возникать.
3. Поскольку вы знаете, что метод "рендеринга" дает проблему, выглядит как сложное вычисление вложенности и браузер Происходит манипуляция домами. Однако если это не проблема, когда на локальном, то проверьте, если рендеринг вызовов для внешних ресурсов и они получают блокирующие вызовы (возможно, потребуется интенсивное использование ajax или асинхронных вызовов на стороне сервера, хотя я предполагаю, что у вас уже есть это на месте.)
4. может потребоваться возможный рефакторинг (чтобы иметь меньшие стеки и возможное использование потоковых / неблокирующих операций ввода-вывода), однако требуется увидеть ваш код, чтобы предложить это.

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

Есть еще два варианта, которые нужно найти и исправить.

1. пользователь Новая реликвия для отслеживания.

Проверьте Этот пост от Хансельмана на использование его в Azure.

2. следуйте Asp.Net лучшие практики MVC

Проверьтеэтот пост на предмет лучших практик.

Также для чтения данных вы можете использовать ADO.NET с хранимыми процедурами вместо Entity Framework, потому что на данный момент EF может иметь некоторые проблемы с производительностью.

Вы компилируете Less или Sass в вашей установке связывания?
Если да, то какой JavaScriptEngineSwitcher вы используете?
Я помню, что у меня была похожая проблема. Пакеты компилируются при первом доступе, и это занимает огромное количество времени.
Решение состояло в том, чтобы переключиться на двигатель V8.