☰

Sehr langsames MySQL auf Azure App Service mit PHP (Wordpress)

tag-icon • tag-icon php azure wordpress azure-web-apps
Sehr langsames MySQL auf Azure App Service mit PHP (Wordpress)

Ich versuche, Probleme mit der sehr langsamen Verbindung von Azure App Services zur Azure-Datenbank zu beheben.

Nach der Wordpress-Migration vom günstigen OVH-Hosting ist mir eine extrem lange TTFB aufgefallen: Anstieg von 300–400 ms auf 1500–3000 ms.

Ich habe das Problem auf App-Dienst - Datenbankverbindungsproblem eingegrenzt. Um das Problem zu lokalisieren, habe ich eine saubere Wordpress-Installation erstellt. Laut P3 - Plugin Performance Profiler erzeugt eine saubere WP-Installation 38 Datenbankabfragen.

Mit dem PHP/MySQL-Plugin für CPU-Leistungsstatistiken habe ich einen MySql-Test ausgeführt:

  • Azure App Service: 20–50 DB-Abfragen/Sekunde
  • Günstiges OVH-Hosting: 200+ DB-Abfragen/Sekunde

Ich denke, das Problem ist ziemlich offensichtlich, wenn der Azure Stack für 200 USD/Monat ungefähr 20-mal langsamer ist als der OVH-Stack für 10 USD (allerdings habe ich herausgefunden, dass selbst Abfragen mit ~40 DB pro Sekunde zu einer TTFB von etwa 300 ms führen können, was mein Ziel ist).

Um dieses Problem zu beheben, habe ich die folgenden Tests/Änderungen versucht:

  • verschiedene App Service Pläne (von dev bis P2v3)
  • verschiedene Azure-Datenbankserver (vom günstigsten bis ~300 USD/Monat)
  • PHP 7.4 und PHP 8.0
  • Apache und nginx (kommt automatisch mit der Änderung von PHP 7/8)
  • Azure Database – Einzel- und flexible Server
  • Azure Database für MySQL und MariaDB
  • Verbindung des App-Dienstes zur Datenbank über öffentliche IP und über VNet-Integration
  • Platzieren der Datenbank in genau derselben Verfügbarkeitszone
  • SSL- und Nicht-SSL-App-/Datenbankverbindungen
  • Datenbankumleitungen mitmysqlnd_azure
  • versuchte Verbindungspersistenz
  • Wordpress im App Service-Docker-Container

Nichts des oben Genanntenhat keine nennenswerte Leistungsänderung bewirkt. Die einzige „Lösung“, die „funktioniert“, ist die Aktivierung des Cache. Wenn der Cache erreicht wird, beträgt die TTFB wie erwartet etwa 100 ms.

Ich habe auch AWS Elastic Beanstalk/RDS und Google App Engine/CloudSQL getestet und sie funktionieren perfekt (~250 ms TTFB sofort einsatzbereit). Eine Azure VM (PHP+ Apache), die mit derselben Azure-Datenbank verbunden ist, funktioniert einwandfrei (<300 ms TTFB).

Mir gehen die Ideen aus. Was übersehe ich? Um es klarzustellen: Ich versuche nicht, einstellige Reaktionszeiten oder ultimative Leistung zu erreichen – 300 ms wären für eine saubere WP-Installation akzeptabel.

Antwort1

Ein paar Dinge, die Sie beachten sollten, da sie in der Frage nicht erwähnt wurden.

  1. Stellen Sie sicher, dass sich die Webanwendung und die Datenbank in derselben Region befinden. Das mag einfach erscheinen, aber ich habe es schon einmal gesehen.
  2. AktivierenImmer aufin den Einstellungen für den Azure App Service. Immer auf: Hält die App geladen, auch wenn kein Datenverkehr vorhanden ist. Wenn Always On nicht aktiviert ist (Standard), wird die App nach 20 Minuten ohne eingehende Anfragen entladen. Die entladene App kann aufgrund ihrer Aufwärmzeit eine hohe Latenz für neue Anfragen verursachen. WennImmer aufeingeschaltet ist, sendet der Front-End-Load Balancer alle fünf Minuten eine GET-Anfrage an das Anwendungsstammverzeichnis. Der kontinuierliche Ping verhindert, dass die App entladen wird.
  3. RezensionBewährte Methoden für App Service.

Antwort2

Ich habe auch das gleiche Problem. Azure ist sehr, sehr langsam und nichts funktioniert?

PP_1, was meinst du mit „Cache aktivieren“? Meinst du Plugins wie WP Rocket?

Antwort3

Habe hier das gleiche Problem. Ich habe einige Tests mit der Verbindung zur Containerinstanz über das Web-SSH durchgeführt und festgestellt, dass es PHP erfordert200-300 ms nur zum Laden der Plugins. h, also ist meine endgültige Schlussfolgerung, dass Azure ein Problem mit PHP hat.

Es würde mich sehr interessieren, ob irgendjemand auf Azure eine anständige Leistung ohne Caching erreicht hat (mit PHP unter Linux).

Wir haben die App schließlich mit einem Startskript konfiguriert, das NGIX so neu konfiguriert, dass Seiten aggressiv zwischengespeichert werden. Das funktioniert bei einigen unserer Websites gut, ist aber alles andere als ideal. Wir haben jetzt eine TTFB von 50 ms für zwischengespeicherte Seiten.

Antwort4

Das Problem liegt in der Art und Weise, wie Azure App Services Speicher verwenden. Aus diesem Grund dauert das Laden der Plug-Ins so lange.

Kurz gesagt: App Services sind nicht in der Lage, Wordpress zu hosten!

verwandte Informationen