Footer hook slowing down each after page refresh when calling _admin_menu_rebuild_links():
Specially following loop:
foreach ($menu_links as $item) {
admin_menu_link_save($item);
}
which is called on my website 288 times and each time it run sql query, so it takes about 9s of all times, which this function calling menu_link_save(), which is running few others sql queries. At the end I've got about 4.478 sql queries called only from links rebuild.
I'm not very deeply which function is doing what, but so in my opinion admin_menu_link_save() function should be optimized somehow.
It's very good module, but at the moment I can't use it at all:
Record high page execution time 1226446254071 ms
Comments
Comment #1
kenorb commentedLook at screenshots.
Comment #2
sunThis should only happen once, i.e. each time the regular menu is rebuilt. Please also try the latest development snapshot, which contains further performance improvements.
Comment #3
sunNo reply probably means that it actually happens only when the menu cache is being rebuilt.
Comment #4
donquixote commentedsubscribe
Comment #5
donquixote commented@sun:
This happens (among others)
- on the module list page, and
- every time you add or remove a content type or field.
It is a serious bottleneck, together with the normal menu_rebuild.
If you don't believe it, xdebug is your friend!
You should consider to fix this once a solution for the normal menu_rebuild is out, see
http://drupal.org/node/512962
Or maybe you can start now already.
Proposed solution:
- Get the $menu from
menu_router_build(nothing new)- Do a "SELECT * FROM {menu_links} WHERE menu_name='admin_menu' to cache this part of menu_links in a variable.
- Find out what needs to change, using the information in memory.
- Write the changes to the DB.
We are looking for a similar solution for the normal menu_rebuild, maybe you can adapt from that once it's ready. If you want to help, would be cool as well.
Thanks!
Comment #6
sunPlease note the version this issue is filed against.
If you have suggestions for improvement of 3.x-dev, then please check whether an existing issue already covers your proposal, or open a new one against 3.x.
Comment #7
donquixote commentedHaving a quick look at the code, I don't see many changes since 6.x-1.1, regarding menu_links rebuild.
(I killed my xdebug, so I can't profile the 3.x dev version)
Anyway, there is no point in having an issue for a specific outdated version.
This was the only issue I could find regarding admin menu rebuild performance. The title is not very useful, though..
I will change the title and version number to something more descriptive, hope that is the correct procedure. Otherwise, other people will complain about duplicate issues.
Comment #8
sunNope, this is a bug report against a version of this module that had a very bad architecture. The rebuilding you are talking of does not exist anymore in 3.x-dev. If you want to speed up 3.x, then please ensure that your findings are still valid, and depending on that, open a new issue against 3.x, please.
Since I was able to test the upgrade path on a real production site just today and it worked flawlessly, 3.x-beta is about to be released in the next days.
Comment #9
donquixote commentedSorry, I was looking in 6.x-3.0-alpha1. Now I see that 6.x-3.x-dev looks completely different. I'm looking forward to your new release!
Just a shame my xdebug doesn't work anymore, so I can't benchmark.
Do you think any of your ideas could be reused in the normal menu_rebuild?
Comment #10
sunThe new code no longer rebuilds any links on its own. Instead, we're taking over all menu items below /admin, removing them from the normal Navigation menu, and using regular menu system functions to retrieve and build the links. That serves the default use-case of 99.9% of all users of Administration menu module.
Comment #11
donquixote commentedInteresting.. I hope this doesn't interfere with the normal menu_rebuild..