admin_toolbar_tools more than doubles number of queries needed during site-install degrading performance

Created on 5 September 2023, over 1 year ago

Problem/Motivation

While debugging an Open Social installation with about 100-200 modules I was surprised to find the install required 124.297 database queries to install. I was even more surprised when I found that ~85.000 of those came from the admin_toolbar_tools module. (Re-installing with admin_toolbar instead of admin_toolbar_tools left only 38.417 database queries)

Profiling showed admin_toolbar_tools_entity_insert, admin_toolbar_tools_entity_update, and admin_toolbar_tools_entity_delete were called a total of about 1100 times in total (901, 177 and 8 respectively). This caused the menu tree to be rebuild a lot of times.

Steps to reproduce

Proposed resolution

Ensure that none of the mentioned hooks have any effect during installation, but only rebuild once post-installation.

Remaining tasks

User interface changes

API changes

Data model changes

πŸ› Bug report
Status

Active

Version

3.4

Component

Code

Created by

πŸ‡³πŸ‡±Netherlands kingdutch

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

Comments & Activities

  • Issue created by @kingdutch
  • πŸ‡¬πŸ‡§United Kingdom Rob230

    We have the same problem when any module is enabled on the site - our deployments failed due to running out of memory. Disabling the admin_toolbar_tools module resolves the problem.

    Our profiling found that having the admin_toolbar_tools module enabled means when a module is enabled, an extra 1.3 GB of memory is used and an extra 21 seconds of load time. Most of the memory is used by admin_toolbar/admin_toolbar_tools/src/Plugin/Derivative/ExtraLinks::getDerivativeDefinitions().

  • πŸ‡ΊπŸ‡ΈUnited States JonMcL Brooklyn, NY

    I am also noticing a memory issue introduced by admin_toolbar/admin_toolbar_tools/src/Plugin/Derivative/ExtraLinks::getDerivativeDefinitions()

    I end up with over 400 items in $links. If I hack the code to exclude some entity types, and get the total count of $links down to around 300, all seems to work well. It doesn't appear to matter which entity types I exclude.

    Strangely, we are most likely to trigger the issue one some node bundles' Manage Field page, but the issue doesn't trigger on other entity types' bundles.

    Sorry, this is probably not very useful information.

    Disabling the module, or returning an empty array from ::getDerivativeDefinitions() does seem to not cause the issue to happen.

  • πŸ‡¬πŸ‡§United Kingdom peterjlord

    Thanks for the great module. This is a goto module for me as it increases usability.
    I'm to having performance issues. I think it's since upgrading to 10.3

    I've had to remove the module to restore my sites performance :(

  • πŸ‡¦πŸ‡ΉAustria daniel.pernold

    My profiling has shown that it is mainly the access checks on the menu items that cause the problem in our projects. If we reduce the depth of the toolbar from 4 to 3, the performance increases significantly.

    /admin/config/user-interface/admin-toolbar -> set 3 here

    The time is spent here: https://git.drupalcode.org/project/admin_toolbar/-/blob/3.x/src/Render/E...

    The same applies, of course, to the analogous implementation in the Gin Toolbar (and any other):
    https://git.drupalcode.org/project/gin_toolbar/-/blob/8.x-1.x/src/Render...

    Generally, if you uninstall the module, there is a huge performance jump.

    Module INSTALLED:
    β†’

    Module UNINSTALLED:
    β†’

Production build 0.71.5 2024