Performance Issue in processMenuLinkTree in Large Menus

Created on 26 June 2023, over 1 year ago
Updated 27 August 2024, 3 months ago

Problem/Motivation

In extremely large menus, Drupal\menu_item_extras\Service\MenuLinkTreeHandler::processMenuLinkTree is taking an extremely long time to run through all the links. On a site with over 200 links in the main menu, New Relic is showing it to take 35s to run. This is slowing the site load time considerably on cache misses.

This comment from 4 years ago on a different issue points to a similar problem: https://www.drupal.org/project/menu_item_extras/issues/3082978#comment-1... β†’

Steps to reproduce

  1. Create a menu with over 200 links (perhaps only 100 would suffice?)
  2. Make sure caching is disabled for this test
  3. Attempt to load any page with the menu on it
πŸ› Bug report
Status

Active

Version

3.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States emclaughlin

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

Merge Requests

Comments & Activities

  • Issue created by @emclaughlin
  • πŸ‡ΊπŸ‡ΈUnited States bakulahluwalia Houston

    Same issue with 8.x-2.19.

  • πŸ‡«πŸ‡·France ratjaune

    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.

  • πŸ‡΅πŸ‡ΉPortugal guilherme-lima-almeida Lisbon

    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.

  • πŸ‡ΊπŸ‡ΈUnited States chertzog Harrisburg, PA, USA

    +1 for same issue

  • πŸ‡ΊπŸ‡ΈUnited States kgthompson

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

  • πŸ‡ΊπŸ‡ΈUnited States chertzog Harrisburg, PA, USA

    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.

  • πŸ‡ΊπŸ‡ΈUnited States azinck

    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.

Production build 0.71.5 2024