Высокая загрузка ЦП в непрерывной веб-работе Azure с многопоточным приложением .NET, состоящим из одного процесса. - PullRequest
1 голос
/ 23 октября 2019

Background-

У меня есть приложение .NET, которое выполняется как один многопоточный процесс в непрерывной веб-работе службы приложений Azure. В приложении есть потоки, которые (1) подключают его к REST API и извлекают данные, которые хранятся в базе данных SQL Azure, (2) запрашивают данные из базы данных SQL, выполняют некоторые вычисления, затем сохраняют результаты, (3) извлекаютдополнительные данные, сравнивает их с отправленным правилом и отправляет уведомления по электронной почте, используя SMTP SendGrid, и текстовые сообщения, используя Twilio.

Это приложение отлично работает в качестве запланированной задачи в виртуальном стандарте Windows Server 2016 [на котором также размещается SQL (База данных 2016)] с 8 ядрами и 8 ГБ ОЗУ, потребляющими всего 0-15% ЦП и только около 100 МБ ОЗУ.

Проблема -

После перемещения в непрерывную веб-работу Azure(Стандартный уровень S1), подключенный к Azure SQL (стандартный уровень S20) и запустив службу, ЦП перешел на 100% как для SQL, так и для службы приложений. Обновлен сервис приложений до уровня P2V2, а база данных - до уровня P1, а CPU - на уровне около 60% для службы приложений и 70% для SQL, но все же намного выше, чем ожидалось.

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

Нет ошибок, и приложение работает нормально, но хотел бы добавить дополнительную функциональность в приложение, но обеспокоено потреблением большего количества ресурсов.

1 Ответ

0 голосов
/ 23 октября 2019

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

Лучше всего использовать Application Insights, чтобы проверить, могут ли они дать вамрука помощи.

Что я скажу, так это то, что производительность SQL ограничивается числом DTU, тогда как ваш локальный экземпляр не будет. А ваш ЦП, снижающийся после масштабирования уровня плана обслуживания приложений с S1 до P2V2, просто указывает на то, что ваш план обслуживания не так эффективен, как ваш локальный сервер, или что в вашем плане обслуживания запущены другие приложения, которые вызывают конфликт ресурсов.

Хорошая статья по устранению неполадок с производительностью Application Insights здесь:

https://docs.microsoft.com/en-us/azure/azure-monitor/learn/tutorial-performance

...