Performance is notoriously slow

Question

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

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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.