Очень медленный mysql в службе приложений Azure с PHP (Wordpress)

Я пытаюсь исправить проблемы с очень медленным подключением Служб приложений Azure к базе данных Azure.

После миграции Wordpress с дешевого хостинга OVH я заметил очень долгое время TTFB: увеличение с 300-400 мс до 1500-3000 мс.

Я сузил проблему до службы приложений — проблема с подключением к базе данных. Чтобы точно определить проблему, я создал чистую установку Wordpress. Согласно P3 — Plugin Performance Profiler, чистая установка WP создает 38 запросов к базе данных.

С плагином статистики производительности процессора PHP/MySQL я запустил MySql Test:

• Служба приложений Azure: 20–50 дБ запросов в секунду.
• Дешевый хостинг OVH: 200+ запросов в секунду

Я думаю, что проблема довольно очевидна, если стек Azure за 200 долларов США в месяц примерно в 20 раз медленнее, чем OVH за 10 долларов США (однако: я обнаружил, что даже запросы ~ 40 дБ в секунду могут привести к TTFB около 300 мс, к чему я стремлюсь. ).

Чтобы решить эту проблему, я попробовал следующие тесты/изменения:

• различные планы службы приложений (от dev до P2v3)
• различные серверы баз данных Azure (от самых дешевых до ~300 долларов США в месяц)
• PHP 7.4 и PHP 8.0
• Apache и nginx (автоматически добавляются при изменении php 7/8)
• Одиночные и гибкие серверы базы данных Azure
• База данных Azure для MySQL и для MariaDB
• подключение службы приложения к базе данных через общедоступный IP-адрес и через интеграцию с vnet
• размещение базы данных в точно такой же зоне доступности
• ssl и не-ssl подключения к приложению/базе данных
• перенаправления базы данных с mysqlnd_azure
• попробовал сохранение соединения
• Wordpress в док-контейнере службы приложений

Ни один из вышеперечисленных внесли какие-либо существенные изменения в производительность. Единственное «исправление», которое «работает», - это включить кеш. Если кеш попал, TTFB составляет около 100 мс, как и ожидалось.

Я также протестировал AWS Elastic Beanstalk/RDS и Google App Engine/CloudSQL, и они работают отлично (~250 мс TTFB из коробки). Виртуальная машина Azure (PHP + Apache), подключенная к той же базе данных Azure, работает нормально (<300 мс TTFB).

У меня нет идей. Что мне не хватает? Чтобы было ясно: я не пытаюсь добиться однозначного времени отклика или максимальной производительности - 300 мс было бы приемлемо для чистой установки WP.

Пара вещей, на которые следует обратить внимание, поскольку они не были упомянуты в вопросе.

1. Убедитесь, что веб-приложение и база данных находятся в одном регионе. Это может показаться простым, но я видел это раньше.
2. Давать возможность Всегда включен в настройках службы приложений Azure. Всегда включен: поддерживает загрузку приложения даже при отсутствии трафика. Если параметр «Всегда включен» не включен (по умолчанию), приложение выгружается через 20 минут без каких-либо входящих запросов. Незагруженное приложение может вызвать большую задержку для новых запросов из-за времени прогрева. Когда Всегда включен включен, внешний балансировщик нагрузки отправляет запрос GET в корень приложения каждые пять минут.Непрерывный пинг предотвращает выгрузку приложения.
3. Рассмотрение Рекомендации по службе приложений.

У меня тоже такая же проблема. Azure очень-очень медленный и ничего не работает?

PP_1, что вы подразумеваете под включением кеша? Вы имеете в виду такие плагины, как WP Rocket?

Здесь такая же проблема. я сделал несколько тестов, подключившись к экземпляру контейнера через веб-ssh, и я обнаружил, что для этого требуется php 200-300 мс только для загрузки плагинов. h, поэтому мой окончательный вывод заключается в том, что у Azure есть проблема с php.

Мне было бы очень любопытно посмотреть, достиг ли кто-нибудь приличной производительности на лазури без кэширования (с php на linux).

В итоге мы настроили приложение с помощью скрипта запуска, который перенастраивает NGIX для агрессивного кэширования страниц, что хорошо работает для некоторых наших сайтов, но далеко не идеально.Теперь у нас есть TTFB 50 мс для кэшированных страниц.