☰

MySQL muito lento no Azure App Service com PHP (Wordpress)

tag-icon • tag-icon php azure wordpress azure-web-apps
MySQL muito lento no Azure App Service com PHP (Wordpress)

Estou tentando corrigir problemas com a conexão muito lenta dos Serviços de Aplicativos do Azure com o Banco de Dados do Azure.

Após a migração do Wordpress para hospedagem OVH barata, notei um TTFB extremamente longo: aumento de 300-400ms para 1500-3000ms.

Limitei o problema ao serviço de aplicativo - problema de conexão com o banco de dados. Para identificar o problema, criei uma instalação limpa do Wordpress. De acordo com o P3 - Plugin Performance Profiler, a instalação limpa do WP cria 38 consultas ao banco de dados.

Com o plugin de estatísticas de desempenho de CPU PHP/MySQL, executei o teste MySql:

  • Serviço de Aplicativo do Azure: consultas de 20 a 50 db/segundo
  • Hospedagem OVH barata: mais de 200 consultas de banco de dados/segundo

Acho que o problema é bastante óbvio se a pilha do Azure de 200 USD/mês for aproximadamente 20 vezes mais lenta que 10 USD OVH (no entanto: descobri que mesmo consultas de ~ 40 db por segundo podem resultar em TTFB em torno de 300 ms, o que pretendo ).

Para corrigir esse problema, tentei os seguintes testes/alterações:

  • diferentes planos de serviço de aplicativo (de dev a P2v3)
  • diferentes servidores de banco de dados do Azure (do mais barato até ~300 usd/mês)
  • PHP 7.4 e PHP 8.0
  • Apache e nginx (vem automaticamente com alteração do php 7/8)
  • Servidores únicos e flexíveis do banco de dados do Azure
  • Banco de Dados do Azure para MySQL e MariaDB
  • serviço de aplicativo para conexão de banco de dados via IP público e via integração vnet
  • colocando o banco de dados exatamente na mesma zona de disponibilidade
  • conexões de aplicativo/banco de dados SSL e não SSL
  • redirecionamentos de banco de dados commysqlnd_azure
  • tentei persistência de conexão
  • Wordpress no contêiner do Docker do Serviço de Aplicativo

Nenhuma das acimafez qualquer mudança significativa no desempenho. A única “correção” que “funciona” é habilitar o cache. Se o cache for atingido, o TTFB será de cerca de 100 ms conforme o esperado.

Também comparei AWS Elastic Beanstalk/RDS e Google App Engine/CloudSQL e eles funcionam perfeitamente (~250 ms TTFB prontos para uso). Uma VM do Azure (PHP+ Apache) conectada ao mesmo banco de dados do Azure funciona bem (<300ms TTFB).

Estou sem ideias. o que estou perdendo? Para ser claro: não estou tentando atingir tempos de resposta de um dígito ou desempenho final - 300 ms seriam aceitáveis ​​para uma instalação limpa do WP.

Responder1

Algumas coisas para observar, já que não foram mencionadas na pergunta.

  1. Certifique-se de que o aplicativo Web e o banco de dados estejam na mesma região. Isso pode parecer básico, mas já vi isso antes.
  2. HabilitarSemprenas configurações do Serviço de Aplicativo do Azure. Sempre: mantém o aplicativo carregado mesmo quando não há tráfego. Quando Always On não está ativado (padrão), o aplicativo é descarregado após 20 minutos sem nenhuma solicitação recebida. O aplicativo descarregado pode causar alta latência para novas solicitações devido ao tempo de aquecimento. QuandoSempreestiver ativado, o balanceador de carga front-end enviará uma solicitação GET para a raiz do aplicativo a cada cinco minutos. O ping contínuo evita que o aplicativo seja descarregado.
  3. AnálisePráticas recomendadas de serviço de aplicativos.

Responder2

Também estou tendo o mesmo problema. O Azure é muito lento e não há nada funcionando?

PP_1, O que você quer dizer com habilitar cache? Você quer dizer plug-ins como WP Rocket?

Responder3

Tenho o mesmo problema aqui. fiz alguns testes de conexão com a instância do container via web ssh e o que descobri é que é preciso php200-300ms apenas para carregar os plugins. h então minha conclusão final é que o Azure tem um problema com o php.

Eu ficaria muito curioso para ver se alguém alcançou um desempenho decente no Azure sem cache (com php no Linux).

Acabamos configurando o aplicativo com um script de inicialização que reconfigura o NGIX para armazenar páginas em cache de forma agressiva, o que funciona bem para alguns de nossos sites, mas está longe do ideal. Agora temos um TTFB de 50ms, para páginas em cache.

Responder4

O problema está na forma como os serviços do Azure App usam o armazenamento. É por isso que os plug-ins demoram tanto para carregar.

Resumindo, os App Services não estão à altura de hospedar Wordpress!

informação relacionada