Comments

robertdouglass’s picture

Version: 6.x-dev » 6.9

The 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.

mysql> select name from system where type ='module' and status=1;
+---------------------+
| name                |
+---------------------+
| webform             | 
| admin_menu          | 
| content             | 
| content_permissions | 
| text                | 
| filefield           | 
| imageapi            | 
| imageapi_gd         | 
| imagecache          | 
| imagecache_ui       | 
| imagefield          | 
| views_ui            | 
| block               | 
| dblog               | 
| filter              | 
| locale              | 
| menu                | 
| node                | 
| path                | 
| system              | 
| trigger             | 
| user                | 
| webform_associate   | 
| workflow            | 
| acquia_agent        | 
| acquia_spi          | 
| pathauto            | 
| token               | 
| views               | 
| devel               | 
+---------------------+
30 rows in set (0.00 sec)
robertdouglass’s picture

StatusFileSize
new30.33 KB

_menu_update_parental_status is also getting called over and over, with UPDATES.

menu_update_parental_status

robertdouglass’s picture

My 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.

robertdouglass’s picture

This might be a duplicate of http://drupal.org/node/302638 - need to confirm, though.

robertdouglass’s picture

Why is there no caching in these lookups that are being done repeatedly?
3002.73 19 menu_link_save SELECT * FROM menu_links WHERE mlid = 18
Can the menu_links change in the process of loading the admin/build/modules page?

damien tournoud’s picture

Category: bug » support
Status: Active » Postponed (maintainer needs more info)

Why is there no caching in these lookups that are being done repeatedly?
3002.73 19 menu_link_save SELECT * FROM menu_links WHERE mlid = 18
Can the menu_links change in the process of loading the admin/build/modules page?

Better 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.

This might be a duplicate of http://drupal.org/node/302638 - need to confirm, though.

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.

Anonymous’s picture

subscribe

robertdouglass’s picture

@Damien Tournoud: There was undue latency between the web and database servers. This was making things much worse.

ainigma32’s picture

@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

robertdouglass’s picture

There should never be 61 duplicate select queries on any page. I don't see this issues as being fixed.

ainigma32’s picture

Fair enough. I guess your question in #5 still stands.

@Damien Tournoud: Care to comment?

- Arie

donquixote’s picture

As 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.

donquixote’s picture

I made a new issue for this, see
Rewrite the function menu_rebuild

stormsweeper’s picture

Robert: 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.

mdupont’s picture

Status: Postponed (maintainer needs more info) » Closed (duplicate)