node add / node edit page performance and scalability

Similar As projects:

• https://www.drupal.org/project/bigmenu →
• https://www.drupal.org/project/metatag_async_widget →
• https://www.drupal.org/project/menu_ui_async_widget →
• https://www.drupal.org/project/trailless_menu →

eval of JS Degrade and general UX/a11y concepts needed.

bigmenu works well for huge menus, however it doesn't affect the node form.

trailless_menu sounds interesting however the reason of the main menu in wxt and node form using the menu system is to drive the breadcrumb so we actually need the trail.

wxt uses the menu_breadcrumb module

Prior to optimising, I had one site with 1500 menu links, the node edit form prior to optimisation would take almost 29 seconds to load from a cold cache. After patching it was down to about 3 seconds

Disabled menu links are always basic page children menu links that by nature do not have children. Landing pages have children. This is why the patch is harmless, do not load the menu links that have no bearing on the node form. Do not waste 50,000 db calls on junk.

I did a full XHProf on this, in our use case with 1500 menu links it is over 50,000 db queries on menu link permissions that have no bearing on anything in the node edit form.

It's especially poor performance for non administrator roles.

The administrator role gets better performance because there's no query to check menu link access

however lesser roles do not have permissions for everything so the whole permissions stack runs for those. The menu link permissions checks are expensive and unneeded in this case.

There's a legitimate justification for this patch to go into a core release , it passes core automated testing btw.

Check the test results on the core patch
🐛 node edit page performance and scalability with thousands of menu links Needs work

For the test scenario I ran with XHProf it was about 400 landing page menu links (parents, enabled links), 2100 children (basic page/children that are not allowed to have children/ disabled menu links)

Performance prior to patching was the best with the administrator role
Performance prior to patching was the worst with lesser roles that did not have the administer menus /administer content permission. These roles incur vastly more hits to the db for queries relating to permissions to access the entity linked by the menu link and for queries to build the link entity it'self.

Performance benchmarks were based on a cold cache node edit/node add page load.

Patch against core tests: 🐛 node edit page performance and scalability with thousands of menu links Needs work
9.3.x: PHP 8.0 & MySQL 5.7 28,509 pass - 100% success
11.x: PHP 8.2 & MySQL 8 30,438 pass - 100% success
10.1.x: PHP 8.2 & MySQL 8 29,676 pass - 100% success