Domain Config loading is resource intensive

Created on 10 September 2021, almost 4 years ago
Updated 28 November 2024, 9 months ago

I defined 83 domains and 3 alias for each domain. After this definition, a 20-second slowdown occurred in the first load after cache cleaning. In addition, there was a significant slowdown in circulation between pages. Even adding a new paragraph to the page made it wait. The modules I set up for the domain were as follows.

  • domain,
  • country_path,
  • domain_access,
  • domain_alias,
  • domain_config,
  • domain_config_ui,
  • domain_content,
  • domain_source,
  • domain_menus,
  • domain_path,
  • domain_path_pathauto,
  • domain_site_settings,
  • domain_theme_switch

I noticed that when I remove the storage->listAll('domain.config.') code in domain/domain_config/src/DomainConfigOverrider.php it speeds up.

I noticed that the Url::fromUserInput line in the domain/domain_source/src/HttpKernel/DomainSourcePathProcessor.php file also slows it down a lot. I eliminated the speed problem by having the Entities here only from $options['entity'].

As a result of these processes, I tested the following domains as multilingual, and saw that there was no problem and my speed problem was solved.
- educ.example.com
- test.example.com
- example.com
- example.com/faculty
- example.com/university

πŸ“Œ Task
Status

Needs work

Version

1.0

Component

Code

Created by

πŸ‡ΉπŸ‡·Turkey seyfettinkahveci

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • First commit to issue fork.
  • @dtfabio opened merge request.
  • πŸ‡§πŸ‡ͺBelgium dtfabio Ninove

    Hi everyone,

    We are using the patch β€˜3232343-2-domain_source_performance_fix.patch’ in production currently and so I tried to re-roll the patch from seyfettinkahveci to the 2.0.x version of the module and created an MR for this.

    Apparently, something did go wrong which meant that not all the modifications from the 2.0.x were present. I tried to fix this, but noticed that something is still not correct.

    I will adjust this and pay better attention to prevent this kind of thing in the future.

    Greetings,

    Fabio

  • πŸ‡§πŸ‡ͺBelgium dtfabio Ninove
  • Issue was unassigned.
  • πŸ‡§πŸ‡ͺBelgium dieterholvoet Brussels

    I'm encountering the same problem. Example: loading /admin/structure/menu/manage/admin takes 45.8 (!) seconds. With 3232343-2-domain_source_performance_fix.patch applied, it only takes 15.3 seconds. I understand that certain code is being disabled that shouldn't be, but a performance impact like this is unacceptable. It impacts every page of your website and especially the ones where a lot of urls are being generated. I'll try to look into this more.

  • πŸ‡§πŸ‡ͺBelgium dieterholvoet Brussels

    The problem is that this module is inherently slow and there isn't much we can do about it. For every generated url, we have to check if there's an associated entity and if there is, we have to check its domain access field to know if we need to rewrite the domain. There isn't really a way around that, that's the whole point of the module.

    According to my profiler, the most expensive calls are Url::fromUserInput() and $this->aliasManager->getPathByAlias(), they account for 80% of the time spent in the path processor. I'll check if these have cheaper alternatives.

  • πŸ‡§πŸ‡ͺBelgium dieterholvoet Brussels

    By using PathValidatorInterface::getUrlIfValidWithoutAccessCheck() instead of Url::fromUserInput() and $this->aliasManager->getPathByAlias(), I'm able to reduce the time from +-46sec to +-34sec. Still slow, but it's something. I'll start a new MR with this change.

    In an ideal world, we wouldn't have to do any route matching at all. $options['route'] already contains the matched route, the problem is that we don't know the route name, which is something that's being proposed in πŸ› Outbound path processors miss the route name Needs work . I'll also create a MR that builds on top of the change in that core issue.

  • πŸ‡§πŸ‡ͺBelgium dieterholvoet Brussels

    dieterholvoet β†’ changed the visibility of the branch 2.0.x to hidden.

  • @dieterholvoet opened merge request.
  • πŸ‡§πŸ‡ͺBelgium dieterholvoet Brussels

    dieterholvoet β†’ changed the visibility of the branch 3232343-performance-problem to hidden.

  • πŸ‡§πŸ‡ͺBelgium dieterholvoet Brussels
  • πŸ‡§πŸ‡ͺBelgium dieterholvoet Brussels

    Using route information from $options, so without doing any route matching ourselves, I got it down to +-15.9s. These changes are on the 3232343-use-info-from-options branch, but they do depend on a patch from πŸ› Outbound path processors miss the route name Needs work . That seems like the way to go, but we'll have to work on getting that core change in first.

  • πŸ‡§πŸ‡ͺBelgium dieterholvoet Brussels

    The issue description is about two separate issues. I'll narrow this down to the DomainSourcePathProcessor issue, since @agentrickard already gave feedback on the (!$this->storage->listAll('domain.config.') check.

  • @dieterholvoet opened merge request.
  • πŸ‡―πŸ‡΄Jordan Qusai Taha Amman

    Update the patch to be working with the drupal core issue

  • πŸ‡§πŸ‡ͺBelgium dieterholvoet Brussels

    Not sure what Drupal core issue you're referring to. Also, work is being done in a MR, so no need to post patches here.

  • πŸ‡«πŸ‡·France mably

    Thanks for your hard work @dieterholvoet!

    Hoping we will get a working solution sooner or later πŸ™

  • πŸ‡§πŸ‡ͺBelgium gillesv Belgium

    Hi @DieterHolvoet, after applying your code changes, I get the following error: "The file "modules/contrib/domain/domain_source/domain_source.services.yml" does not contain valid YAML: Unexpected characters near "," at line 9 (near "- '@domain.negotiator',")."

    It seems like the change in domain_source.services.yml contains a yml-formatting issue: while commas after yml list items seem to be valid yaml, my setup (using lando) seems to have issues parsing it. It could be fixed by either removing the commas or placing the list between square brackets and removing the hyphens (like the formatting was before).

  • πŸ‡§πŸ‡ͺBelgium dieterholvoet Brussels

    @gillesv fixed!

  • πŸ‡ΉπŸ‡·Turkey emircan erkul Turkey

    Confirm that #24 https://www.drupal.org/project/domain/issues/3232343#comment-16031559 πŸ“Œ Domain Config loading is resource intensive Needs work works great. With this patch module page loading dropped ~3.5s to 1.2s

    Thank you all & https://www.drupal.org/u/seyfettinkahveci β†’

  • πŸ‡«πŸ‡·France mably

    Hi @dieterholvoet,

    While waiting for core to provide the route_name and route_parameters in the processOutbound method options parameter, I worked on an in-house lightweight route matcher that extract those values from the path.

    You can see it implemented in MR 177 for issue 3271978 β†’ .

    Could it be a temporary fix until core issue is fixed? What do you think?

  • πŸ‡«πŸ‡·France mably
  • πŸ‡§πŸ‡ͺBelgium dieterholvoet Brussels

    I did some profiling. I loaded the /admin/structure/menu/manage/admin page under different conditions:

    Conclusion: good improvement, but not as good as the solution with the core patch, so I would leave this issue open for the time being. The new solution introduces a lot of custom code, but if you're willing to maintain all that I'd say go for it!

  • πŸ‡«πŸ‡·France mably

    Fixed by issue πŸ› DomainSource Outbound Path Processor endless Loop Closed: cannot reproduce .

    This will approximately cut execution time by half.

    For even better performance, the following Core patch has to be applied: πŸ› Outbound path processors miss the route name Needs work .

Production build 0.71.5 2024