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

Ответ 1

Я отправляю ответ, хотя он не решен, но я на 99% уверен, что нашел основную проблему.

Случается, что когда я выпускаю, каждое представление должно быть построено. Для создания представления требуется ~ 15 секунд, что и показывает новое реликвии в моем последнем обновлении.

Это приводит к двум временным решениям и к одному большему вопросу: почему создание представления так медленно?

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

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

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

Большое спасибо за вашу помощь и поддержку - по крайней мере сейчас я могу справиться с этим.

Ответ 2

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

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

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

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

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

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

ОБНОВЛЕНИЕ: Поскольку это было связано с просмотром, я могу предложить решение, которое я нашел очень полезным. Установка пакета 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);
        }
    }
}

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

Такой подход должен решать проблемы производительности с помощью представлений.

Ответ 3

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

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

2. Ошибки сервера регистрируются в Application Insights?

3. На экране "Диагностика и решение проблем" вы видите что-либо подозрительное в журналах трассировки неудачных запросов?

Ответ 4

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

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

Ответ 5

Есть еще два варианта поиска и исправления.

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

Проверьте это сообщение от hanselman на его использование в Azure.

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

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

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

Ответ 6

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

Ответ 7

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

В журналах IIS я обнаружил, что каждые десять минут к моей службе приложений отправляется пинг с чего-то под названием ReadyForRequest/1. 0+. Я не могу найти дополнительную информацию об этом запросе в Интернете, но он точно совпадает с нашей десятиминутной проблемой тайм-аута. Мы создали службу поддержки активности, которая посещает наш сайт каждую минуту, и сообщает о времени отклика. Каждые десять минут время отклика изменяется от 0,3 до 10-15 секунд, и это точно соответствует времени этих вызовов ReadyForRequest.

Обычно мы получаем один вызов ReadyForRequest/1. 0+ (LocalCache) и три вызова ReadyForRequest/1. 0+ (AppInit).

GET / - 80 - 10.0.208.4 ReadyForRequest/1.0+(LocalCache)
GET / - 80 - 10.0.208.4 ReadyForRequest/1.0+(AppInit)

У нас есть запрос к нашему представителю Microsoft, но пока они также не могут определить, что вызывает эти звонки.

Может быть, кто-то еще увидит это и получит дальнейшее понимание будущих искателей решений.