Django Rest Framework очень медленно работает на Azure

Спасибо, что поделились подробностями и шагами, которые вы уже попробовали. Не могли бы вы уточнить, получаете ли вы какое-либо конкретное сообщение об ошибке или просто медленное время отклика? Существует ряд проблем, которые могут повлиять на производительность, например:

• Сетевые запросы занимают много времени
• Код приложения или база данных
• Запросы неэффективны Приложение использует много памяти/процессора
• Приложение аварийно завершается из-за исключения

Чтобы изолировать проблему. Попробуйте выполнить следующие шаги по устранению неполадок:

1. Наблюдение и мониторинг поведения приложения
2. Собирать данные
3. Разбираться в проблеме
.

Хотелось бы предложить вам перейти к вашему веб-приложению на портале Azure и выбрать лезвие "диагностика и решение" вашего веб-приложения> нажмите на Linux web app Slow в разделе Popular troubleshooting tools, информация, представленная здесь, будет полезна для устранения неполадок.

Для увеличения скорости работы drf попробуйте удалить ненужные приложения в INSTALLED_APPS и MIDDLEWARE, это может помочь увеличить производительность django rest framework.

Конечно, спасибо, что поделились скриншотами. Чтобы уточнить, вы, возможно, знаете, что служба App Service всегда запускается в плане App Service. При создании плана App Service в любом регионе для этого плана создается набор вычислительных ресурсов в этом регионе.

Все приложения, которые вы поместили в этот план App Service, запускаются на этих вычислительных ресурсах, как определено вашим планом App Service. Каждый план App Service определяет:

• Операционная система (Windows, Linux)
• Регион (Запад США, Восток США и т.д.)
• Количество экземпляров виртуальных машин
• Размер экземпляров ВМ (малый, средний, большой)
• Ценовой уровень (Free, Shared, Basic, Standard, Premium, PremiumV2, PremiumV3, Isolated, IsolatedV2)

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

Предлагаем вам обратиться к этому подробному пошаговому руководству Переместить приложение на другой тарифный план App Service

Обратите внимание, что вы можете переместить приложение на другой план App Service, если исходный план и целевой план находятся в одной группе ресурсов и географическом регионе.

Для масштабирования рекомендуется выполнить подробные шаги, указанные в разделе : Масштабирование количества экземпляров вручную или автоматически Вы можете выбрать запуск приложения на нескольких экземплярах. Масштабирование не только дает вам больше возможностей для обработки, но и обеспечивает некоторую отказоустойчивость. Если процесс на одном экземпляре завершается, другие экземпляры продолжают обслуживать запросы. Масштабирование можно задать в ручном или автоматическом режиме.

Далее вы можете рассмотреть возможность увеличения масштаба, поскольку новый ценовой уровень PremiumV3 предоставляет более быстрые процессоры, SSD-накопители и в четыре раза больше памяти к ядрам, чем существующие ценовые уровни (в два раза больше, чем уровень PremiumV2). Благодаря преимуществу в производительности вы сможете сэкономить деньги, запустив свои приложения на меньшем количестве экземпляров.

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

Подробнее: Обзор плана Azure App Service

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

1. Если это еще не сделано, включите функцию Always On. По умолчанию веб-приложения выгружаются, если они простаивают в течение некоторого периода времени. Это позволяет системе экономить ресурсы. В режиме Базовый или Стандартный вы можете включить функцию Всегда включен, чтобы приложение было загружено все время.

2. В приложении App Service в левой навигации нажмите Diagnose and solve problems - Отметьте плитку "Инструменты диагностики" > "Доступность и производительность" & "Лучшие практики" .

3. Установите загрузку процессора на 75% для scale-out condition или 25% для условия scale-in в качестве теста и посмотрите, есть ли разница (to avoid flapping условие/я так понимаю, что вы уже проанализировали загрузку процессора)

4. Изолировать/избежать outbound TCP limits проще, так как ограничения задаются размером вашего рабочего. Вы можете увидеть ограничения в Sandbox Cross VM Numerical Limits - TCP Connections- - Чтобы избежать исходящих TCP ограничений, вы можете либо увеличить размер ваших рабочих, либо масштабироваться горизонтально.

5. Устранение периодических ошибок исходящего соединения в Azure App Service - (чтобы изолировать исчерпание портов).

6. если есть несколько приложений в рамках одного плана App Service Plan, распределите приложения across multiple app service plans для получения дополнительных уровней вычислений (для дальнейшей изоляции проблемы/ поделитесь более подробной информацией об этом в разделе "комментарий" ниже)

7. Review the logs для получения более подробной информации по этому вопросу.

Примечание: Linux в настоящее время является рекомендуемым вариантом для запуска приложений Python в App Service, и я полагаю, что вы используете версию App Service Linux.

После взаимодействия с командой Microsoft проблема заключалась в том, что мой гибкий сервер Azure и служба App находились в разных регионах, один был в North South Africa, а другой - в East US. Поэтому после того, как все они оказались в одном регионе, проблема была решена.

Во-вторых, у меня было поле, которое содержало и текст, и изображения (base 64), я использовал Django summernote, он обеспечивает WYSIWYG опыт, поэтому он может хранить по умолчанию все изображения и текст вместе в одном поле, поэтому я оптимизировал его, теперь скорость супер быстрая.