We have a fairly complex Drupal site with around 60 contrib modules, which ends up having around 450 links in the admin menu (this includes links to all the normal admin pages, plus links to create content of about 15 types, and all the issue queue links for the various projects added by admin menu).

Now on a normal cache flush without admin menu installed we get about 160 queries. With admin menu enabled we get an astounding 6,800 queries! What in the world could admin menu need that many queries for?

As it turns out admin menu does about 800 queries on our site just to run menu_rebuild(), which I think is probably outside the scope of what we can actually fix without rearchitecting admin menu. However for every individual link in the menu we're currently doing 2 queries to pull the menu item from the menu_links table (so that's 900 additional queries for us), then about 9 more queries for every menu item when it is saved back into the database (another 4,000 queries). I think the actual number of queries done per link depends on how many parents it has.

I think it would make sense to take a dual approach here to solve these problems:
- Pre-load the entire admin_menu menu from the menu_links table (1 query total instead of 2 queries per link).
- Only re-save the link if the link has actually changed in some way (saves about 9 queries per link).

This tremendous number of SQL queries also is the cause of many "links missing from my admin menu" problems. Since admin menu may cause PHP to run out of memory or time out (we experienced this problem occasionally on a 128MB memory limit PHP installation), the menu only gets half-built before running out of memory and links go missing until the next time the cache is flushed and the menu is rebuilt again.

I know that Admin Menu (both 1.x and 3.x) is not getting much attention in D6 these days, but this inefficiency problem is likely a source of a lot of frustrations.

CommentFileSizeAuthor
admin_menu_efficiency.patch2.81 KBquicksketch
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

quicksketch’s picture

After a conversation with Sun I tried out the 3.x version to see what improvements are there concerning performance. Overall admin_menu does not seem to have any effect on Flushing Caches in that version, so this problem is likely isolated to the legacy version.

sun’s picture

Assigned: Unassigned » pwolanin

The only person who might look into this is @pwolanin. 6.x-1.x is obsolete and discontinued as far as I'm concerned.

mgifford’s picture

Version: 6.x-1.6 » 7.x-3.0-rc3

Let's just say we've been running into the same problem.

Jumps up to 10k queries though when you have a big menu & it's multi-lingual.

So many performance blogs point to admin menu. I didn't believe them, figuring it might be a matter of a 1-200 extra queries that could be turned off.

However, we were able to demonstrate a drop in thousands of queries (after clearing the cache), by simply disabling the admin menu.

sun’s picture

Version: 7.x-3.0-rc3 » 6.x-1.x-dev

This issue only applies to 6.x-1.x, and it's a known issue, which is caused by the architecture of 6.x-1.x.

3.x uses Drupal core's native/built-in menu system functionality to build and render the menu. If there is an issue with 3.x, then please file a separate issue (although it's likely that issue would have to be moved into core).

mgifford’s picture

Thanks @sun. Will try to follow-up.

Rob230’s picture

I definitely am having this problem with the latest admin_menu 6.x-3.x-dev. #756494: Admin. Links Disappeared on admin_menu and Navigation Block gave me the clues to increase MySQL max_allowed_packet, which appeared to fix it, but no longer does. I don't know what changed.

The behaviour is exactly as described here. If I flush all caches the admin menus appear correctly. But clicking on any other page means there is only some of the content management links and none of the others menu links appear. It basically seems to reach a certain point in that first menu before giving up.

This is also on a site with a large number of content types (nearly 30) and with a lot of installed modules, although I've tried to disable some. There are also a lot of fields on the content types, again maybe 20-30 per content type. So you can imagine the number of links in the menu. There are 1933 rows in the menu_links table for admin links and 2825 in total. If what quicksketch says is true about the number of queries done for every menu item then this is slightly ridiculous.

In the cache_admin_menu table I see admin_menu has data of [BLOB - 32B] in the only row.

In the cache_menu table I see links:admin_menu:tree-data:############# has data of [BLOB - 645.6 KiB], [BLOB - 666.1 KiB], [BLOB - 735.1 KiB] and one [BLOB - 2.3 MiB].

Does that seem about right for the number of menu links? I don't understand how the caching works. The navigation, primary-links and secondary-links all only have 1 tree-data entry in the cache table, whereas the admin_menu one seems to get a new one of a different size every time I visit a page (this is with me being the only person browsing the site shortly after clearing the cache).

The 2.3MiB one appears immediately after clearing the cache, after which the new ones are around 645KiB.

Any ideas of what is going on?

jstoller’s picture

@Rob230, your issue may be related to #649584: Partial menu disappearance (cut) when "Page compression" is on. There is a simple patch there to fix the issue of admin menu only partially rendering on some platforms.

truls1502’s picture

Status: Needs review » Closed (outdated)

It seems it is outdated because Drupal 6 is EOL (End-of-life) and will no longer be supported.

In case if you or anyone is still facing on Drupal 7/8, please to reopen it, change the version and provide with more information and a screenshot which might help us to troubleshoot. :)