Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
When logging in with admin_menu active, I see a 100% Apache server load that delays log-in by 20 seconds. Everything else in Drupal works reasonably fast considering the circumstances, but this very annoying log-in delay for an administrator log-in really sticks out. I cannot image that developers intentionally wanted to annoy administrators this way and I feel therefore free to designate this as a bug.
Comment | File | Size | Author |
---|---|---|---|
#5 | XHProfWithHackedAdminMenu.zip | 6.11 KB | ñull |
#3 | XHProfAdmin_Menu.html_.zip | 12.63 KB | ñull |
Comments
Comment #1
ñull CreditAttribution: ñull commentedBy using XHProf I could determine that by activating admin_menu I see a rise of 5M function calls or some 230 times more. This might be caused by the great number of (group) menus this site has. A way to improve performance might be to reduce reliance on menu related function calls and in stead rely more on database queries.
Comment #2
sunWe recently fixed #1841884: cache_admin_menu table truncated 400+ times when clearing the cache, but that's part of RC4 already.
If you are able to distill what exactly gets called due to admin_menu during login, I'm more than happy to investigate further and work on a fix with you.
Comment #3
ñull CreditAttribution: ñull commentedThe only thing I can share (attached) at this point are the two reports of the profiler, one without and one with admin_menu. Unfortunately I cannot give you access to the site because this concerns an Intranet. In a couple of weeks I might have time to set up an anonymised test system that replicates the problem. Then you can click on links of each function in the list and get more detail.
Comment #4
ñull CreditAttribution: ñull commentedIn this intranet of a large decentralised NGO there are many groups that maintain their own group menu. In total including the global menus there are 162 menus!
I am not sure what menus get processed by admin_menu at log-in. I am just guessing here (no time to get into the details of the code). If it goes indistinctly through all the menus, then may be the solution to this problem is to exclude all og_menu group menus from processing.
Comment #5
ñull CreditAttribution: ñull commentedWith the following hack I reduce processing to only system menus (added condition module=system to the queries). Attached the profiler report to see the difference. The answer is definitely in finding smarter queries.
Comment #6
ñull CreditAttribution: ñull commentedI noticed that after applying my hack still a lot of processing time is wasted. I still see all the group menus in the admin_menu. In core Drupal these og_menus are not listed either when you look at admin/structure/menu so why should they be in the admin menu.
The idea of a group menu is that the group maintains it, not the site administrator. With a large number of group menus, like in my case, I need to scroll down at the very bottom to find the menu settings in admin_menu, far from being practical.
Still need to work on this, but that will have to wait until I have more time.
Comment #7
johnvThis problem is not only with og_menus, but with every menu that adds entities to a menu (like taxonomy_menu).
Try this test case:
- disable admin_menu,
- add a new node/group: the page is fast
- add a new node/group and add it to a menu : the page is slow
IMO, this is a special case of a more generic problem.
The root cause (low performance) is described here:
#1905144: High load time for admin_menu upon user login/menu refresh
#1978176: Build menu_tree without loading so many objects
If you do not want to show your groups in the initial admin_menu, you might want to work on:
#420816: On-demand loading of dynamic paths and local tasks #1
So, is this a duplicate?
Also, can you create a proper diff/patch? ATM it is difficult to see the modifications you made.
Comment #8
truls1502I am sorry for no reply until now.
There are many issues regarding this module admin_menu which is a bit difficult for us to follow up since some of the issues might be already outdated, or is already fixed by the module or any other modules or itself core which means that the problem might no longer need to be fixed.
We can see that the issue has been created for a few years ago, I hope it is okay for you that I am postponing the issue, and give you around two weeks. If you still face the problem, could you tell us the step by step when until you get the error message or what is frustrated you, and a list of modules you are using related to admin_menu and a screenshot that might help us? So it makes us easier to reproduce your issue.
However, after two weeks with no feedback - we will close this issue. So in case, you noticed it after the issue is closed, do not hesitate to reopen it like and fill information which is mentioned above.
So before giving us a feedback, do you mind to test it again with our latest 7.x-3.x-dev?
Thank you for understanding! :)
Comment #9
truls1502This issue has been automatically marked as closed because it has not had recent activity after the last post.
However, if you or someone is still facing the same issue as described to the issue, could you please to re-open the issue by changing the status of the issue, and add an explanation with more details which can help us to reproduce your situation.
Again, thank you for your contributions! :)