У меня есть служба приложений на ценовом уровне P1V2 , которую я использую в качестве бэкэнда для своего мобильного приложения. У меня обычно не так много пользователей, но через пару месяцев go был пик пользователей, которые делали службу приложения непригодной к использованию за несколько часов.
Из метрики я вижу, что процессор и Что касается памяти, служба приложений работает нормально, но когда возникает проблема, мы видим, что число потоков становится все выше и выше. Кажется, что каждый запрос съедает другой поток, но ни один из потоков не освобождается, и поэтому никакие запросы не выполняются в течение времени. Когда это происходит, если мы перезагружаем службу приложения, количество потоков на мгновение уменьшается, но затем снова взрывается. Единственное смягчение, которое у меня есть сейчас, - это масштабирование службы, когда это происходит, что занимает пару минут и будет стоить мне больших денег и усилий.
Я поиграл с настройкой минимальных и максимальных потоков в пуле потоков, а также ограничении количества максимальных одновременных запросов на процессор, но ничего не помогло. Я могу воспроизвести проблему только с 5 наиболее часто используемых API. Все они делают асинхронных вызовов в SQL базу данных, также размещенную на azure. Я использую async / await , и контекст удаляется после вызова. Я использую Entity Framework в качестве нашего ORM.
План обслуживания приложений, за который я плачу, должен был бы легко справляться с нагрузкой, и при отсутствии внезапного пика запросов он без проблем справляется. Но когда служба выходит из строя, она может оставаться недоступной в течение нескольких часов, а перезапуск или остановка службы совсем не помогают. Мы вернули бэкэнд к более старым версиям, и проблема все еще показывает.
Я могу легко воспроизвести проблему, просто взорвав бэкэнд с запросами. Ниже вы можете найти пример того, что происходит. Одна вещь, которая указывает на нас, состоит в том, что независимо от того, сколько запросов мы отправляем, мы никогда не видели длину очереди Http go up.
