Mysql foarte lent pe Azure App Service cu PHP (Wordpress)

Încerc să remediez problemele legate de conexiunea foarte lentă a Azure App Services la Azure Database.

După migrarea Wordpress de la găzduire OVH ieftină am observat TTFB extrem de lung: creștere de la 300-400ms la 1500-3000ms.

Am restrâns problema la serviciul aplicației - problemă de conectare la baza de date. Pentru a identifica problema, am creat o instalare curată pentru Wordpress. Conform P3 - Plugin Performance Profiler, instalarea WP curată creează 38 de interogări la baza de date.

Cu pluginul de statistici de performanță a procesorului PHP/MySQL am rulat MySql Test:

• Azure App Service: 20-50 db interogări / secundă
• Găzduire OVH ieftină: 200+ interogări db/secundă

Cred că problema este destul de evidentă dacă stiva Azure de 200 USD/lună este de aproximativ 20 de ori mai lent decât OVH de 10 USD (cu toate acestea: am aflat că chiar și interogări de ~40 db pe secundă pot duce la TTFB în jur de 300 ms, ceea ce țintesc ).

Pentru a remedia această problemă, am încercat următoarele teste/modificări:

• diferite planuri de servicii pentru aplicații (de la dezvoltare la P2v3)
• diferite servere Azure Database (de la cel mai ieftin la ~300 USD/lună)
• PHP 7.4 și PHP 8.0
• Apache și nginx (vin automat cu modificarea PHP 7/8)
• Servere unice și flexibile Azure Database
• Azure Database pentru MySQL și pentru MariaDB
• serviciu de aplicație la conexiune la baza de date prin IP public și prin integrare vnet
• plasarea bazei de date în exact aceeași zonă de disponibilitate
• conexiuni ssl și non-ssl pentru aplicații/baze de date
• redirecționări baze de date cu mysqlnd_azure
• a încercat persistența conexiunii
• Wordpress în containerul docker App Service

Nici una dintre cele de mai sus a făcut orice modificare semnificativă a performanței. Singura „remediere” care „funcționează” este activarea memoriei cache. Dacă memoria cache este lovită, TTFB este de aproximativ 100 ms conform așteptărilor.

De asemenea, am evaluat AWS Elastic Beanstalk/RDS și Google App Engine/CloudSQL și funcționează perfect (~250 ms TTFB din cutie). O VM Azure (PHP+ Apache) conectată la aceeași bază de date Azure funcționează bine (<300 ms TTFB).

Am rămas fără idei. Ce îmi lipsește? Pentru a fi clar: nu încerc să obțin timpi de răspuns cu o singură cifră sau performanță maximă - 300 ms ar fi acceptabile pentru o instalare WP curată.

Am si eu aceeasi problema. Azure este foarte foarte lent și nu funcționează nimic?

PP_1, Ce vrei să spui prin activarea memoriei cache? Te referi la pluginuri precum WP Rocket?

Câteva lucruri de privit, deoarece nu au fost menționate în întrebare.

1. Asigurați-vă că aplicația web și baza de date sunt în aceeași regiune. Poate părea de bază, dar l-am mai văzut.
2. Permite Mereu pe în setările pentru Azure App Service. Mereu pe: păstrează aplicația încărcată chiar și atunci când nu există trafic. Când Always On nu este activat (implicit), aplicația este descărcată după 20 de minute fără nicio solicitare. Aplicația descărcată poate provoca o latență mare pentru noile solicitări din cauza timpului său de încălzire. Când Mereu pe este pornit, echilibratorul de încărcare front-end trimite o solicitare GET la rădăcina aplicației la fiecare cinci minute.Ping-ul continuu împiedică descărcarea aplicației.
3. Revizuire Cele mai bune practici pentru serviciul de aplicații.

Aveți aceeași problemă aici. Am făcut un test de conectare la instanța containerului prin ssh web și ceea ce am găsit este că este nevoie de php 200-300 ms doar pentru a încărca pluginurile. h, deci concluzia mea finală este că Azure are o problemă cu PHP.

Aș fi foarte curios să văd dacă cineva a atins performanțe decente pe azure fără cache (cu php pe linux).

Am ajuns să configurăm aplicația cu un script de pornire care reconfigurează NGIX pentru a stoca agresiv paginile, ceea ce funcționează bine pentru unele dintre site-urile noastre, dar este departe de a fi ideal.Acum avem un TTFB de 50 ms, pentru paginile stocate în cache.