Лазурное веб-приложение имеет медленные и безответные нагрузки (30 с + загрузка)

У меня очень большая проблема с Azure Webapp и хотелось бы услышать предложения.

Что мы переживаем:

Когда я быстро перейду на наш сайт. Средняя нагрузка составляет около 1 секунды и отвечает как ожидалось.

Однако, как только pr. 10-20 минут, мы получаем очень холодную нагрузку - где это 30-60 секунд +.

Это имело бы смысл, если бы на сайте не было посетителей, и было холодно, но у нас есть 10 + посетителей онлайн на веб-сайте все рабочие часы с 3-5 запросами на минуту.

Эта дополнительная нагрузка абсолютно неприемлема, конечно.

Любые идеи?

Наша настройка:

У нас есть два лазурных веб-приложения. Один для производства и один для разработки.

Производство - это "СТАНДАРТНЫЙ МАЛЫЙ", с автоматическим масштабированием, когда процессор достигает 65-85%.

Мы имеем базу данных S2 с 10 gb.

Это довольно простой стандартный сайт ASP.NET MVC с некоторыми текстами, формами и несколькими удаленными соединениями.

Единственное "нестандартное" - это 3 миллиона индексированных страниц, которые просматривают базу данных (загрузка страницы составляет около 1 с). Это получает много посетителей от Google. Мы также получаем некоторые обходы от Google, так как у нас есть карта сайта с 3mio + страницами.

Данные с монитора:

EDIT: данные с нового монитора.

Веб-приложение:

База данных:

Конфигурации:

Веб-приложение для производства:

База данных:

Наши попытки:

1: Всегда включен.

Мы всегда пробовали много раз, но иногда в течение первых 30 минут до 6 часов сайт просто падает и не возвращается **. Это, конечно, огромная проблема и не является решением.

2: Работа на виртуальной машине.

У нас довольно стабильная и тонкая настройка на виртуальной машине на Azure (4gb RAM), которая работает нормально. У нас были довольно медленные ответы, но они работали прилично. Однако мы хотели бы использовать веб-приложение для "аутсорсинга" масштабирования и платформы для Azure - мы просто не можем принять эту скорость:)

**

Он остается невосприимчивым навсегда до таймаута. Я попробовал два сценария: один, где остановилась и запустила веб-приложение, а вторая, где мне пришлось выполнить перераспределение

Ответ 1

Я нашел решение.

Решение было не только в одном месте, но и в нескольких местах.

Позвольте мне попробовать погрузиться.

Основная задача - 3 миллиона страниц, которые мы проиндексировали. Google сканирует между 50-150 тыс. Страниц в день, что можно увидеть в инструментах Google для веб-мастеров:

99,9%. Из этих страниц был уникальный тип адресных страниц. Я нырнул в них и узнал, что они взяли 1.5-2 с по умолчанию (!). Это было даже медленным, когда вы проходили тест.

Шаг №1 состоял в том, чтобы создать новый индекс и оптимизировать код. 5x Улучшение производительности там.

Теперь это не решит проблему самостоятельно. Я также обновил базу данных до нового S3... Не решил проблему полностью (но все же лучше).

Я также обновил наше Azure Web App до версии 7gb - и THEN начали работать.

Однако у нас все еще была небольшая проблема каждые 30 минут. Я вошел в нашу виртуальную машину и нашел старую консольную работу, которая содержала некоторый контент в порядке... Я приостановил эту работу.

Ни один из этих находок не остался в одиночестве - но после того, как все это было исправлено - мы снова хорошо, а веб-сайт - приемлемым!

Ура!

Ответ 2

Чтобы помочь дополнительно изолировать узкое место, не могли бы вы использовать новый портал Ibiza по адресу http: portal.azure.com.

Старый портал, скриншоты выше, показывает 54-минутные средние значения. Очевидно, что с 5-минутными средними значениями и DTU на ~ 80%, вероятно, будут периоды, когда все DTU потребляются, и это может быть узким местом.

Используя новый портал, эти графики DTU представляют собой 15-секундные средние значения, и эта более тонкая гранулярность может указывать на узкое место. Можете ли вы перейти на новый портал и вставить еще несколько графиков?

Спасибо, парень