Что может быть причиной такого рода Azure Web Site?

У меня довольно богатое развертывание на Azure: 4 больших экземпляра, обслуживающих около 300-600 запросов в секунду. В нормальных условиях: "Среднее время отклика" составляет от 70 до 150 мс, но иногда оно может вырасти до 200-300 мс, но это абсолютно нормально.

Хотя, один или два раза в день (не в "Rush Hours" ), я вижу такую ​​картинку на вкладке "Мониторинг веб-сайта":

Azure Web Site Monitoring

Таким образом, количество запросов в минуту значительно падает, среднее время отклика увеличивается на 3 минуты, а через некоторое время все возвращается к норме.

Во время этого "Blackout" отбрасывается только 0,1% запросов (Http Server Errors с таймаутом), другие запросы просто ждут в очереди и обычно обрабатываются через несколько минут. Хотя, не все клиенты готовы ждать: - (

Использование памяти под 30% все время, загрузка процессора составляет до 40-50%.

Что я уже проверил?:

  • Трассировка для запрограммированных запросов: они были отключены в случайных местах.
  • Дросселирование для Azure Storage и других используемых компонентов: без дросселирования.
  • Я также попытался маршрутизировать весь трафик через CloudFlare: и увидел те же проблемы.

Что может быть причиной таких проблем? Что я могу проверить далее? Спасибо всем заблаговременно!

Обновление 1: BenV предложил хорошую вещь, чтобы попробовать, но, к сожалению, ничего не показал:-(
Я настроил процессы, перерабатывающие каждые 500 тыс. Запросов, а также добавленные рабочие узлы, поэтому загрузка процессора сейчас составляет менее 40% в течение всего дня, но все еще появляются отключения.

Обновление 2: Project использует ASP.Net MVC 4.

Ответы

Ответ 1

У меня была такая же проблема. Для меня я видел много ошибок WinCache в моих журналах.

Всякий раз, когда сайт терпит неудачу, в журнале будет много ошибок WinCache. WinCache - это то, как IIS обрабатывает PHP, чтобы попытаться ускорить обработку. Это встроенное надстройка Microsoft, включенная по умолчанию в IIS и во всех сайтах Azure. WinCache будет зависеть и вместо того, чтобы перерабатывать и продолжать, он будет потреблять все файлы памяти и файлов на экземпляре, по сути, блокируя его.

Я добавил новое приложение в Azure Portal для сканирования папки для изменений настроек php.ini.
d:\home\site\ini

Добавлен файл в d:\home\site\ini\settings.ini который содержит следующие

wincache.fcenabled=1
session.save_handler = files
memory_limit = 256M
wincache.chkinterval=5
wincache.ucachesize=200
wincache.scachesize=64
wincache.enablecli=1
wincache.ocenabled=0

Это делает несколько вещей: 
wincache.fcenabled=1

Включает кэширование файлов с использованием WinCache (я думаю, что по умолчанию все равно)

session.save_handler = files

Изменяет обработчик сеанса из WinCache (по умолчанию Azure) на стандартный файл, основанный на снижении нагрузки на кеш-память.

memory_limit = 256M
wincache.chkinterval=5
wincache.ucachesize=200
wincache.scachesize=64
wincache.enablecli=1

Устанавливает размер WinCache до 256 мегабайт на поток и ограничивает общий размер кеша. Это заставляет WinCache очищать старые данные и чаще использовать кэширование.

wincache.ocenabled=0

Это большой. ОТКЛЮЧИТЬ кеширование операционного кода WinCache. Это WinCache, кэширующий реальные скрипты PHP в память. Файлы по-прежнему кэшируются из первой, но PHP интерпретируется как нормальный и не кэшируется в большие двоичные файлы.

Из-за того, что каждый раз, когда я работаю с 3-мя днями, я столкнулся с авариями на сайте Azure, которые выглядят как ваши до 120 дней подряд без каких-либо проблем.

Удачи!