Score:0

Very slow mysql on Azure App Service w/ PHP (Wordpress)

cn flag

I am trying to fix issues with very slow Azure App Services to Azure Database connection.

After Wordpress migration form cheap OVH hosting I noticed extremely long TTFB: increase from 300-400ms to 1500-3000ms.

I narrowed the problem to app service - database connection issue. To pinpoint the problem I created clean Wordpress installation. According to P3 - Plugin Performance Profiler, clean WP installation creates 38 database queries.

With PHP/MySQL CPU performance statistics plugin I ran MySql Test:

  • Azure App Service: 20-50 db queries / second
  • Cheap OVH hosting: 200+ db queries / second

I think the problem is pretty obvious if 200 USD/mo Azure stack is roughly 20 times slower than 10 USD OVH (however: I have found out that even ~40 db queries per second can result in TTFB around 300ms, which I am aiming for).

To fix this issue I tried the following tests/changes:

  • different App Service Plans (from dev to P2v3)
  • different Azure Database servers (from cheapest to ~300 usd/mo)
  • PHP 7.4 and PHP 8.0
  • Apache and nginx (comes automatically with php 7/8 change)
  • Azure Database Single and Flexible servers
  • Azure Database for MySQL and for MariaDB
  • app service to database connection via public IP and via vnet integration
  • placing database in exactly same availability zone
  • ssl and non-ssl app/database connections
  • database redirections with mysqlnd_azure
  • tried connection persistance
  • Wordpress in App Service docker container

None of the above made any significant change in performance. The only "fix" that "works" is to enable cache. If cache is hit, TTFB is around 100 ms as expected.

I also benchmarked AWS Elastic Beanstalk/RDS and Google App Engine/CloudSQL and they work perfect (~250 ms TTFB out of the box). An Azure VM (PHP+ Apache) connected to same Azure Database works fine (<300ms TTFB).

I am out of ideas. What am I missing? To be clear: I am not trying to achieve single digit response times or ultimate performance - 300ms would be acceptable for a clean WP installation.

Doug avatar
in flag
I also found this attempting to integrate a PHP app (Moodle) with multiple back-end databases (Postgres, Maria, MySQL), with and without Redis cache. Database performance was great yet Moodle was unusable. My conclusion at the time was that PHP was accessing thousands of files for each Moodle request and the app service was not behaving well under that condition. Moved it to a small VM and had flawless performance, so abandoned the app service path. Absolutely no problem with other web apps, but large PHP platforms like Moodle (and seemingly WP) seem to provoke a file storage bottleneck.
cn flag
@pp_1 In what region was the app service hosted?
cn flag
@czerspalace I have tested West, North Europe and Central, West US
Score:0
cn flag

I am also having the same issue. Azure is very very slow and there is nothing working?

PP_1, What do you mean by enabling cache? Do you mean plugins like WP Rocket?

cn flag
Yes, by cache I mean plugins like WP Rocket.
Score:0
gb flag

A couple things to look at since they were not mentioned in the question.

  1. Ensure the web app and database are in the same region. This may seem basic but I have seen it before.
  2. Enable Always On in settings for the Azure App Service. Always On: Keeps the app loaded even when there's no traffic. When Always On is not turned on (default), the app is unloaded after 20 minutes without any incoming requests. The unloaded app can cause high latency for new requests because of its warm-up time. When Always On is turned on, the front-end load balancer sends a GET request to the application root every five minutes. The continuous ping prevents the app from being unloaded.
  3. Review App Service Best Practices.
cn flag
Thank you. DB and app are in same region and I even tested same AZ. Always on is enabled default when you create app via portal.
Score:0
ph flag

Have the same problem here. i've made some test connecting to the container instance via the web ssh and what i've found is that it takes php 200-300ms just to load the plugins. h so my final conclusion is that azure has a problem with php.

I'd be very curious to see if anybody has reached decent performance on azure without caching (with php on linux).

We ended up configuring the app with a startup script that reconfigures NGIX to aggressively cache pages, witch works well for some of our sites, but it's far from ideal. We now have a TTFB of 50ms, for cached pages.

Score:0
in flag

The issue is with the way Azure App services use storage. This is why the plugins take so long to load.

In short, App Services are not up to hosting Wordpress!

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.