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?
Comment | File | Size | Author |
---|---|---|---|
#6 | 2765911.6.patch | 4.13 KB | alexpott |
| |||
#5 | Screenshot 2016-07-29 14.40.15.png | 749.55 KB | smk-ka |
Comments
Comment #2
ayalon CreditAttribution: ayalon commentedWe 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?
Comment #3
alexpott@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.
Comment #4
ayalon CreditAttribution: ayalon commented@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
Comment #5
smk-ka CreditAttribution: smk-ka commentedCachegrind 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.Comment #6
alexpottHow 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...
Comment #7
smk-ka CreditAttribution: smk-ka commentedWorks great, thanks!
A slight performance improvement to core would be to check
$dependencies
is not empty, otherwise the result of thearray_replace()
operation will simply be an empty array, which means the sorting could be skipped.Comment #9
mpotter CreditAttribution: mpotter at Phase2 commentedNice! 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.
Comment #10
mpotter CreditAttribution: mpotter at Phase2 commentedAlex: be sure to ping me when this improvement gets added to core so we can then remove this override service.
Comment #12
mpotter CreditAttribution: mpotter at Phase2 commentedOops, forgot to add the new file to the repo. Fixed in 129a0ea.