Closed (duplicate)
Project:
Drupal core
Version:
6.9
Component:
menu system
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
11 Feb 2009 at 20:06 UTC
Updated:
25 Jul 2011 at 14:02 UTC
Jump to comment: Most recent, Most recent file

Comments
Comment #1
robertdouglass commentedThe admin/build/modules page continues to baffle me. When I load it I'm getting over 2,500 queries: Executed 2580 queries in 950329.53 milliseconds.
Here are the modules I have enabled.
Comment #2
robertdouglass commented_menu_update_parental_status is also getting called over and over, with UPDATES.
Comment #3
robertdouglass commentedMy setup has the webserver and database on different machines, meaning there is a bit more latency in PHP<-->MySQL communication. I'm wondering if this is exacerbating the race condition by opening the window wider.
Comment #4
robertdouglass commentedThis might be a duplicate of http://drupal.org/node/302638 - need to confirm, though.
Comment #5
robertdouglass commentedWhy is there no caching in these lookups that are being done repeatedly?
3002.73 19 menu_link_save SELECT * FROM menu_links WHERE mlid = 18Can the menu_links change in the process of loading the admin/build/modules page?
Comment #6
damien tournoud commentedBetter question: why are those look-ups so slow on your setup? 3s for 20 straight-forward primary-key retrievals? Really? :)
I would say something is really broken in your setup.
The UPDATE part (that your describe in #2) is indeed a duplicate of #302638: No-op and slow queries during menu rebuild. The SELECT part should not be an issue under any decent database setup.
Comment #7
Anonymous (not verified) commentedsubscribe
Comment #8
robertdouglass commented@Damien Tournoud: There was undue latency between the web and database servers. This was making things much worse.
Comment #9
ainigma32 commented@robertDouglass: Can we set this issue to fixed; since the slow SELECT queries were caused by a configuration issue and the UPDATE queries are handled in #302638: No-op and slow queries during menu rebuild ? Or do you want to pursue the amount of queries further?
- Arie
Comment #10
robertdouglass commentedThere should never be 61 duplicate select queries on any page. I don't see this issues as being fixed.
Comment #11
ainigma32 commentedFair enough. I guess your question in #5 still stands.
@Damien Tournoud: Care to comment?
- Arie
Comment #12
donquixote commentedAs the stack trace says, the respective functions are all called by menu_rebuild().
I don't really see why menu_rebuild needs so many queries. Maybe I am missing a point, but if I were to write a menu_rebuild function I would do it like this:
- One big query to load the menu_links table into a php array
- Do some computations
- Write the changes to the DB.
I am sure this would be much faster than the current implementation.
Comment #13
donquixote commentedI made a new issue for this, see
Rewrite the function menu_rebuild
Comment #14
stormsweeper commentedRobert: Hopefully we can get this backported soon: #193366: execute various rebuilds when modules are submitted Basically I'm unsure of when it's ok to start a new issue for the backport Once it's committed to HEAD?
I benchmarked the no-op patch and it doesn't really make the menu_rebuild() call go any faster, I think the extra PHP mangling in the patch just shifts the load to the application layer.
Comment #15
mdupontSee #512962: Optimize menu_router_build() / _menu_router_save() where a solution is worked on.