This feels like a repeat post but I can't find an actual answer. I just installed Drupal 8.4.4 on an Azure App Service (S3 Standard 4core 7GB RAM / PHP 7.0.6) and Azure Database for MySQL (Standard 100 computes / v5.6.26.0). I've been told the host isn't the issue.

Out of the box, the admin side is incredibly slow, like 4-5 seconds per click. I enabled page caching, and CSS/JS are aggregating. Dog slow. I worked through this and created my content types, added a couple of extensions, and enabled BigPipe (reported to help but didn't).

What am I missing? How do I improve performance before I ask my content authors to start loading up content?

Status report from Drupal. (I have since fixed the reported trusted host settings error)

Performance of the page in Chrome. Looks like 2.8s waiting on the page

I created a test.php file, and queried mysql directly, the key_value table, and dumped all of that to the page, about 576 rows, and it returned instantly. Appears to be Drupal specifically?

Devel bar on public page 182 DB queries

Devel bar on admin page 233 DB queries

  • Comments are not for extended discussion; this conversation has been moved to chat. – Clive Apr 16 at 13:51
  • Can you test the site in another environment? – Ziftman Apr 17 at 16:31

Odds are you have some code that is doing an external http request. If MySQL is fast, php isn’t that slow; leaves something like an http request. If you don’t know where to look, a cachegrind via xdebug is how to pinpoint the slow part.

  • using devel it shows no HTTP calls – David Lozzi Mar 2 at 17:24

There's some sort sub-optimal LAMP/Drupal configuration that's occurring here. As the case with most these types of problems, you run through the common checklist of Drupal slow stack performance problems (e.g. DB caching, app server caching, web server config, etc.) to see if you're hitting one of the common instances that can occur.

Past that, you need to deep dive into all performance profiling tools for your stack to find out where in the web/app/DB request pipeline the bottleneck is occuring. From comment groking (you last mention trying a fresh Drupal install), it sounds like this might be a new stack setup so you might want to consider a freshly provisioned stack & Drupal install on Azure following the practices recommended by MS so you can find a known-to-be-reliable setup on your hosting provider.

That's about the whole scope that you can address from the Drupal perspective since this is more a question about a host environment than it is about the CMS application itself.

  • sadly that Msft article is 4 years old, and doesnt match the current Azure landscape or Drupal version... but i pulled what i could out of it – David Lozzi Apr 19 at 0:58
  • I noticed as such, I took a quick look at what MS has on offer and that was the most authoritative source. Whatever the case, one would think that MS would have a default stack setup that would play nice with any LAMP-based app. – Shawn Conn Apr 19 at 1:35
up vote 1 down vote accepted

It appears Azure's docker container services, which App Services leverages, is the cause of the problem.

Two big pains with Azure's app service (as explained by Azure support):

First, the docker containers are spread out across multiple drives, and PHP/Drupal's nature in using file caching causes it to run slower than it should.

Second, setting PHP settings to setup xdebug for instance, were lost when the service was restart. A "feature" in Azure, the container since it's a PHP image, everything outside of the home directory gets reset. This could be fixed by using an empty container, but then I'd probably still have the first issue.

My solution was to spin up a VM in Azure and manage it there. Runs MUCH faster, more reasonably now.

THANK YOU ALL

One possibility is that Drupal caching will attempt to make use of APCu caching if it is available. Generally not a bad thing since it's fast. However, sometime the host system has this available but it is set to a very small memory size. This can cause problems.

You might try adding the following to your settings file to force Drupal to ignore this:

  $settings['cache']['default'] = 'cache.backend.database';

  # Force common chainedfast bin to use database.
    $settings['cache']['bins']['discovery'] = 'cache.backend.database';
    $settings['cache']['bins']['bootstrap'] = 'cache.backend.database';
    $settings['cache']['bins']['render'] = 'cache.backend.database';
    $settings['cache']['bins']['data'] = 'cache.backend.database';
    $settings['cache']['bins']['config'] = 'cache.backend.database';
    $settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.database';

If you have memcache available, you can change the database part to memcache.

Another thought is to check your opcache size (in php setting via status report). It might be too small and your PhP code is having to be parsed into op codes to run. My servers are using 96MB for D8.

Finally, can you change your PhP version to 7.1? I know that 8.5 has some requirements for it and will not install via composer with 7.0.

  • I added the settings, didn't seem to help. Looking at opcache size, I'm not sure what setting I should be looking at, opcache.max_file_size which is 0, and opcache.file_cache is set to no value... – David Lozzi Apr 19 at 1:33

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.