Have seen a bad performance hit when navigating to features after 2754477 hit core. As of 8.1.4 I had to increase the script execution timeout to avoid (in my case) a 504 timeout error.

As far as I can tell the issue is due to the call out on line 1094 (1089 on dev) to getDependentEntities taking a lot longer than before.

'dependents' => array_keys($dependency_manager->getDependentEntities('config', $name)),

If anyone is here looking for a quick fix this is what got me across the line when hosting on PHP-FPM and Nginx. https://easyengine.io/tutorials/php/increase-script-execution-time/

I am using features to move things around for a large site. I have not had a chance to check dev yet but the code "I think" is causing the issue still exists.

Anyone else seen an issue like this?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Gravypower created an issue. See original summary.

ayalon’s picture

We have the same problem. The latest version (beta-6) with CORE 8.1.6 is almost unusable. Not even the command line is usable.

I also see, that is is because of the latest patch as mentioned above.

Unfortunatly I have no idea how to improve the situation. But maybe someone has some imputs?

alexpott’s picture

@ayalon can you detail precise steps to reproduce? If can reproduce the performance issues locally I should be able to work out what's going on.

ayalon’s picture

@alexpott:
Thx alot four your help. I think it's related to the number of modules and content types you have. It somehow does not scale. With only 6 additional modules everything is fine. But then it gets worser and worser.

I prepared a full setup for you, where you can reproduce it. On our instance is much more obivious because we have more content types. But even in an empty installation you have to wait for more than a minute if you click on the "Article" bundle on features.

https://github.com/ayalon/drupal8-zurb

smk-ka’s picture

Cachegrind snapshot

Cachegrind snapshot showing 226 calls to ConfigDependencyManager::getDependentEntities(), resulting in roughly 1.9 million calls to ::sortGraph() before hitting the default 30 sec timeout. The call to sortGraph was added in #2754477: Unexpected config entity delete due to dependency calculations.

alexpott’s picture

Status: Active » Needs review
FileSize
4.13 KB

How about this...

I think we should open a core issue to do something like this in core but we can work around it quicker here...

smk-ka’s picture

Status: Needs review » Reviewed & tested by the community

Works great, thanks!

A slight performance improvement to core would be to check $dependencies is not empty, otherwise the result of the array_replace() operation will simply be an empty array, which means the sorting could be skipped.

  • mpotter committed 4aef3be on 8.x-3.x authored by alexpott
    Issue #2765911 by alexpott, smk-ka: Features performance issue
    
mpotter’s picture

Status: Reviewed & tested by the community » Fixed

Nice! Somebody here was complaining about the slow performance recently and I was kind of dreading digging into it, and here I find a patch that already fixes it.

Committed to 4aef3be.

mpotter’s picture

Alex: be sure to ping me when this improvement gets added to core so we can then remove this override service.

  • mpotter committed 129a0ea on 8.x-3.x authored by alexpott
    Issue #2765911 by alexpott, smk-ka: Features performance issue
    
mpotter’s picture

Oops, forgot to add the new file to the repo. Fixed in 129a0ea.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.