У меня очень странная проблема с Azure Web App, и я очень расстраиваюсь.
Мы используем наше приложение очень быстро и быстро реагируем на это, однако, если мы не используем его примерно десять минут, он имеет очень холодный старт (~ 10-20 секунд). Это холодное начало происходит только тогда, когда оно связано с базой данных. Когда это немного напоминает, когда мы выпускаем веб-приложение.
Наши попытки
Используя Application Insights внутри Azure, мы настраиваем этот ping каждые 5 минут:
Выбросы всегда вызваны моими развертываниями (без использования слотов для развертывания прямо сейчас). Однако эта страница входа не вызывает нашу базу данных, поэтому мы не видим "холодного" начала в этих данных.
Настройка приложения должна быть прочной. Наше веб-приложение размещено в Северной Европе с Always on
:
Мы просто перенесли все настройки в новый план обслуживания ресурсов/приложений, чтобы убедиться, что наша проблема запуталась с другими нашими приложениями. Новый план обслуживания приложений - это Standard 1 small
, который не должен быть проблемой. Глядя на наше потребление, я не беспокоюсь и, возможно, даже попробую меньшую услугу, которую я буду делать после решения нашей проблемы:
Наша база данных SQL также размещена в Северной Европе (проверенные местоположения в миллиард раз, потому что я сделал эту ошибку раньше).
Как и в случае с сервисом приложений, мы выбрали "слишком большое" аппаратное обеспечение, чтобы убедиться, что это не вызывает проблемы (стандартные S0: 10 DTU). Использование смехотворно низкое:
Мы используем непрерывное развертывание (Deployment options
в меню Azure), но, глядя на развертывания, он не должен постоянно развертывать что-то:
Фрустрация приходит в приложение супер отзывчив, когда он работает. Когда он "нагревается", каждая страница загружается за считанные секунды, так же как мое среднее время отклика отображается в нашем веб-приложении:
Но эти цифры просто неверны, когда мы (или наши пользователи!) Используем наше приложение. Здесь мы очень часто ощущаем нагрузку + 10-20 секунд в первый раз.
Кто-нибудь имеет ЛЮБОЕ представление? Любые намеки? Вы не представляете, насколько я благодарен.
EDIT & UPDATE 1:
Я решил настроить еще несколько тестов. Теперь мне удалось получить реальные данные, показывающие нашу проблему, вызвав другую страницу. По иронии судьбы, эта страница НЕ вызывает базу данных, поэтому, хотя я думал, что это проблема с базой данных, это не похоже на это. См. Вызов здесь (тенденция продолжается +24 часов).
Странно, насколько стабильно это составляет ровно ~ 10 секунд. И тренд, кажется, не каждые 10-20 минут, но ближе к каждым 5 минутам - с точно таким же интервалом между ними:
EDIT & UPDATE 2:
Я копаю еще. Оказывается, есть пара очень интересных историй: "медленные" 11 секундные вызовы из edit 1, это только из восточных стран США и с одной конечной точки (http://prntscr.com/jcv69w) и
Самое интересное, что я нашел, это следующее:
У самого приложения нет кэширования. Я использую Entity Framework, который, как я предполагаю, использует некоторое кэширование, но все.
Я зашел в наше приложение и щелкнул его в Chrome. Я узнал, что страницы, которые я уже посетил, показывали мгновенно (с данными из БД), но если бы я открывал новую страницу, она медленно загружалась. Казалось, что некоторые объекты кэшируются при первом открытии страницы.
Затем я попытался открыть приложение в новом браузере. Если бы я открыл страницу, которую раньше открывал в Chrome, она открывалась бы мгновенно. Если бы я открывал новую страницу, которую я раньше не нажимал, она имела бы нагрузку ~ 10 секунд.
Мое лучшее предположение прямо сейчас заключается в том, что я использую структуру Entity Framework, которая почему-то дает проблемы.
ИЗМЕНИТЬ 3:
Просто добавил щедрость и настраивает много протоколирования. Я добавил MiniProfiler, но не могу заставить его работать на производстве (отображается только по местным запросам).
Я также добавил регистрацию в global.asax для Application_Start
и Application_BeginRequest
и Application_EndRequest
чтобы увидеть некоторые и статус там. Скоро будет обновляться с выводами.
EDIT 4:
Итак, теперь у меня есть первые интересные номера. Приложение не перерабатывается. Application_Start
вызывается только один раз.
Я вижу разницу во времени, войдя в EndRequest
и BeginRequest
. Я вижу, что есть несколько вызовов, которые занимают больше, чем +15 секунд между этими двумя... Но когда сайт теплый, он занимает ~ 0,5-2 секунды в зависимости от страницы. Поэтому между началом и концом запроса происходит что-то очень странное. Отладка дальше!
EDIT 5:
Получил MiniProfiler для работы. Ниже приведен пример медленной нагрузки (~ 15 секунд):
Следующим шагом является добавление отслеживания Entity Framework и даже еще одна строка для линейных вызовов. Я получаю деньги в базе данных!
EDIT 6:
Окидоки, я был неправ. это метод рендеринга, который замедляется - не база данных! Я не знаю, как отладить это... В google!
EDIT 7:
Время для другого обновления. Статус: ничего не было решено.
Поэтому я пробовал много вещей:
1) Я попытался отключить все типы кэширования (предотвращение кеширования в ASP.NET MVC для определенных действий с использованием атрибута), и у меня такое же поведение. Первая загрузка? Медленный. Следующая нагрузка? Быстро. Подождите 5-10 минут, такое же поведение так не решено.
2) У меня были некоторые пользовательские вещи в моем файле startup.auth с 5-минутной задержкой. Удалены. Не проблема.
3) Я использовал пользовательский атрибут для авторизации. Я удалил это.
4) Я обновил свою реализацию Entity Framework, чтобы она работала за каждый запрос.
Я очень расстраиваюсь. Следующий шаг:
A) Попробуйте сделать 5-10 версий одной и той же страницы (без _layout, с макетом, с базой данных, без базы данных, с инъекцией зависимостей, без... все эти вещи), поэтому см., Могу ли я найти шаблон.
B) Попробуйте переместить хостинг на виртуальную машину, чтобы узнать, разрешает ли она проблему
EDIT 8 - НОВАЯ РЕЛИКСА ДОБАВЛЕНА:
Теперь я добавил новую реликвию. Две очень страшные вещи следующие (я нашел и воспроизвел ошибку!):
И интерфейсный мудрый (часть браузера New Relic), есть недостаток ~ 15s между двумя запусками:
http://prntscr.com/jevgeg vs http://prntscr.com/jevgix, в котором нет ничего.