MySQL muy lento en Azure App Service con PHP (Wordpress)

Question

Estoy intentando solucionar problemas con la conexión muy lenta de Azure App Services a Azure Database.

Después de la migración de Wordpress desde el alojamiento económico de OVH, noté un TTFB extremadamente largo: aumento de 300-400 ms a 1500-3000 ms.

Reduje el problema al servicio de aplicaciones: problema de conexión de la base de datos. Para identificar el problema, creé una instalación limpia de Wordpress. Según P3 - Plugin Performance Profiler, una instalación limpia de WP crea 38 consultas de bases de datos.

Con el complemento de estadísticas de rendimiento de CPU PHP/MySQL ejecuté la prueba MySql:

• Servicio de aplicaciones de Azure: consultas de 20 a 50 db/segundo
• Alojamiento OVH barato: más de 200 consultas de base de datos/segundo

Creo que el problema es bastante obvio si una pila de Azure de 200 USD/mes es aproximadamente 20 veces más lenta que OVH de 10 USD (sin embargo: descubrí que incluso consultas de ~40 db por segundo pueden dar como resultado un TTFB de alrededor de 300 ms, que es lo que estoy buscando). ).

Para solucionar este problema, probé las siguientes pruebas/cambios:

• diferentes planes de App Service (desde dev hasta P2v3)
• diferentes servidores de Azure Database (desde el más barato hasta ~300 usd/mes)
• PHP 7.4 y PHP 8.0
• Apache y nginx (viene automáticamente con el cambio de php 7/8)
• Servidores únicos y flexibles de Azure Database
• Base de datos Azure para MySQL y MariaDB
• servicio de aplicación a conexión de base de datos a través de IP pública y mediante integración vnet
• colocar la base de datos exactamente en la misma zona de disponibilidad
• Conexiones de aplicaciones/bases de datos SSL y no SSL
• redirecciones de bases de datos conmysqlnd_azure
• Probé la persistencia de la conexión.
• Wordpress en el contenedor acoplable de App Service

Ninguna de las anterioresrealizado algún cambio significativo en el desempeño. La única "solución" que "funciona" es habilitar el caché. Si se alcanza la memoria caché, el TTFB es de alrededor de 100 ms, como se esperaba.

También comparé AWS Elastic Beanstalk/RDS y Google App Engine/CloudSQL y funcionan perfectamente (~250 ms TTFB listos para usar). Una máquina virtual de Azure (PHP+ Apache) conectada a la misma base de datos de Azure funciona bien (<300 ms TTFB).

Se me acabaron las ideas. ¿Qué me estoy perdiendo? Para ser claros: no estoy tratando de lograr tiempos de respuesta de un solo dígito o el máximo rendimiento: 300 ms serían aceptables para una instalación de WP limpia.

Answer 1

Un par de cosas a tener en cuenta ya que no se mencionaron en la pregunta.

1. Asegúrese de que la aplicación web y la base de datos estén en la misma región. Esto puede parecer básico pero lo he visto antes.
2. PermitirSiempre encendidoen la configuración de Azure App Service. Siempre encendido: Mantiene la aplicación cargada incluso cuando no hay tráfico. Cuando Always On no está activado (predeterminado), la aplicación se descarga después de 20 minutos sin ninguna solicitud entrante. La aplicación descargada puede provocar una alta latencia para nuevas solicitudes debido a su tiempo de preparación. CuandoSiempre encendidoestá activado, el equilibrador de carga de front-end envía una solicitud GET a la raíz de la aplicación cada cinco minutos. El ping continuo impide que se descargue la aplicación.
3. RevisarMejores prácticas de servicio de aplicaciones.

Answer 2

Yo también tengo el mismo problema. ¿Azure es muy lento y no funciona nada?

PP_1, ¿Qué quieres decir con habilitar el caché? ¿Te refieres a complementos como WP Rocket?

Answer 3

Tengo el mismo problema aquí. Hice algunas pruebas para conectarme a la instancia del contenedor a través de la web ssh y lo que encontré es que se necesita php200-300 ms sólo para cargar los complementos. h entonces mi conclusión final es que Azure tiene un problema con php.

Tendría mucha curiosidad por ver si alguien ha alcanzado un rendimiento decente en Azure sin almacenamiento en caché (con PHP en Linux).

Terminamos configurando la aplicación con un script de inicio que reconfigura NGIX para almacenar en caché páginas de manera agresiva, lo que funciona bien para algunos de nuestros sitios, pero está lejos de ser ideal. Ahora tenemos un TTFB de 50 ms, para páginas almacenadas en caché.

Answer 4

El problema está en la forma en que los servicios de aplicaciones de Azure utilizan el almacenamiento. Es por eso que los complementos tardan tanto en cargarse.

En resumen, ¡los servicios de aplicaciones no están preparados para alojar Wordpress!