Performance Issue in processMenuLinkTree in Large Menus

Same issue with 8.x-2.19.

Same for me. The administration menu inherited of menu_item_extras functionalities.

Huge TTFB : 40 seconds to load a page !!!!!!

Updating from 8.x-2.19 to 3.x just fixed the Admin Toolbar hover issue, not the performance issue.

I'm having the same problem.

I am having the same issue after after adding a menu field that reference to a taxonomy that have a lots of terms.

+1 for same issue

Subscribing, processMenuLinkTree is taking up a lot of time in my slow processes in NewRelic

For some real world data, here is a screenshot from NewRelic with a before/after when i replaced Menu Item Extras with TB Megamenu.

Pre-replacement we were seeing average 5s page loads. After disabling menu item extras and replacing with TB Megamenu, we are seeing sub 1s page loads.

I can just confirm as well. The function is the most heavest currently on the site and takes 1/3 of total load time.

I've attempted to performance-test the merge request here. I'm having a hard time coming up with reliable results showing it improving things. I've used Siege to test a set of pages, attempting differing amounts of concurrency, as both an authenticated user and not and cannot reliably get it to show a performance difference.

The best I've been able to achieve is using a profiler comparing loading 2 pages, both of which have menus on them:

Pre-patch:
- Page 1: 17.8s
- Page 2: 8.02s

Post-patch:
- Page 1: 17.8s
- Page 2: 6.6s

Understandably the savings is limited to the second page (though, interestingly, I might have thought the use of loadMultiple might have been realized in the first page load but I'm not seeing that). And on the load of the 2nd page I can see virtually all of the savings comes in the processMenuLinkTree method, going from 2.07 s → 290 ms.

However, it's somewhat strange to me that I can't seem to find meaningful improvement when using Siege across a wider array of pages. I'm hitting each page once concurrency of 1 to maximally benefit from caching (though I've experimented with other values), always running it immediately after a cache clear and it's just not consistently showing me a benefit despite repeated tests.

I've tested it with and without the patch using moderated/high synthetic non-logged traffic (20 concurrent) hitting the same hundred nodes and views during one hour each and it doesn't make any difference: it remains at almost half of a second using a menu of 30 elements and 7 fields.

Other graphs of execution time or memory have the same shape.

@DavisA - Thank you for the patch! (https://git.drupalcode.org/project/menu_item_extras/-/merge_requests/37.... if folks want the direct link).

It helped my team solve timeout issues with a site with ~1200 menu depth/links. Without the patch, uncached sites were constantly timing out. With the patch, while it is slow to load, timeouts no longer occur.

Confirming that the changes in the MR #40 I posted reduce response time from ~25 seconds to ~1500 ms for a large enterprise drupal 10 site with 1200 menu links.

Before:

After:

This also resolves that cache stampedes I was observing in redis previously as hgetall was 4.5 seconds and is now ~370 ms

Thanks for spotting this issue.

I can confirm that applying this patch to a website with a significant number of menu entries reduces the number of SQL queries by 33%.

It seems to have stopped working with Drupal 10.4. When I downgrade the core to 10.3, it works again.

LogicException: The database connection is not serializable. This probably means you are serializing an object that has an indirect reference to the database connection. Adjust your code so that is not necessary. Alternatively, look at DependencySerializationTrait as a temporary solution. in Drupal\Core\Database\Connection->__sleep() (line 1920 of /var/www/web/core/lib/Drupal/Core/Database/Connection.php).

Backtrace
#0 [internal function]: Drupal\Core\Database\Connection->__sleep()
#1 /var/www/web/core/lib/Drupal/Component/Serialization/PhpSerialize.php(14): serialize(Array)
#2 /var/www/web/core/lib/Drupal/Core/Cache/DatabaseBackend.php(284): Drupal\Component\Serialization\PhpSerialize::encode(Array)
#3 /var/www/web/core/lib/Drupal/Core/Cache/DatabaseBackend.php(227): Drupal\Core\Cache\DatabaseBackend->doSetMultiple(Array)
#4 /var/www/web/core/lib/Drupal/Core/Cache/DatabaseBackend.php(215): Drupal\Core\Cache\DatabaseBackend->setMultiple(Array)
#5 /var/www/web/modules/contrib/menu_item_extras/src/Service/MenuLinkTreeHandler.php(139): Drupal\Core\Cache\DatabaseBackend->set('menu_link_conte...', Array, -1, Array)
#6 /var/www/web/modules/contrib/menu_item_extras/src/Service/MenuLinkTreeHandler.php(213): Drupal\menu_item_extras\Service\MenuLinkTreeHandler->getMenuLinkItemContent(Object(Drupal\menu_item_extras\Entity\MenuItemExtrasMenuLinkContent), 0, false)
#7 /var/www/web/modules/contrib/menu_item_extras/menu_item_extras.module(255): Drupal\menu_item_extras\Service\MenuLinkTreeHandler->processMenuLinkTree(Array, 'main')
...

probably related: https://www.drupal.org/project/drupal/issues/3400483 🐛 LogicException: The database connection is not serializable (for string translations in Ajax callback) [META] Active

OK, sorry for the false alarm - it looks like the actual issue was caused by the upgrade of the drupal/menu_multilingual module (from 1.0.0-beta3 to 1.0.0). Also, the patch https://www.drupal.org/files/issues/2024-05-21/3366412-12.patch → was added, so the problem likely originates from there.

After removing the patch and downgrading drupal/menu_multilingual to the previous version, the patch from here started working again