Wayfinder performance

Having an issue with wayfinder taking like 7-9 seconds to build a menu ...

Here is how I am calling it:



You can see it in action here: http://oncologyeducation.ca/blank-test-page.html ~ only the main menu is being called there - mind you it is a large menu, but not 9 seconds worth [IMO]

- right now on that page wayfinder is being cached, however when the sites cache is cleared [several times a day] every page takes 8 seconds longer to load!

Any thoughts?

Check if you can make use of this snippet: https://github.com/Mark-H/MenuExtended
This works super-fast and great.

Wayfinder is just slow.

big problem with that...

"MenuExtended only supports TWO levels (parent, child) right now. You can increase the depth but it’ll do nothing (1)"

-thanks for looking though.

-sean

Okay, then try to set a specific level like 5. And try if it's better to set StartID=`2,3,4,5` (children of 0 = root)

That does make a difference, but by the time I reach level 5 or so, the time is back up to 8 or 9 seconds again.

beginning to wonder if it is the silly length of some of the menu titles.....

-sean

UPDATE:
did some testing, removing html from the snippets, only outputting the page id as the link text, removing the actual links. nothing helps. It appears that wayfinder starts to become pretty inefficient above 3 menu levels. [ed. note: sean69 last edited this post 14 years, 8 months ago.]

Whoah, I'm not surprised! That's a huge amount of items there! I doubt *any* snippet that builds menus would be able to process that within a reasonable few seconds. If I were to build multiple levels into MenuExtended that might be a tad faster than Wayfinder as it collects all the data at once (Wayfinder takes it level by level iirc, but either way Wayfinder has more overhead anyway), but if I were to guesstimate, that would still take like 4 seconds minimum.

It looks like you're not using active states or something like that, so I do have an idea on what could help: caching the menu *system wide* instead of on a page-by-page basis which is what the MODX caching does by default. Basically wrap Wayfinder (or MenuExtended when the multiple levels is built in) with a custom snippet that writes it to cache (making sure it's within the "resource" partition of the cache to ensure it gets cleared when the cache does), and if available gets the data from the cache as well.

Basically that would mean you have the first delay only once - when any page with the menu is first requested (plugin OnDocFormSave getting requesting any front end resource through cURL if you want to automate that too). After that it just collects it from the cache which shouldn't really take longer than a bunch of ms.

Makes sense?

Hi Mark;

Saw your reply tweet - thanks, answered that here, 'more than 2 levels deep' ...

I agree that the menu is [unnecessarily] huge and the time to find a solution would be much better spent convincing the client that there is a much better way to organize their content/data [rolls eyes, looks away]

~but~

that's not the case. and caching is an issue since there are 4 or 5 different user groups who get different menu options once logged in ... what you are seeing is really only about 60% of the content. [and irritatingly enough about 80% of those pages are landing pages... the client should just condense things!!]

So other than a UI makeover, I've been tinkering with the idea of a stored procedure or query that can assemble the menus and return it as a result set.... the content records are there - the menu wrapper snippets are there, we just need to convince mysql to assemble them correctly.... though that's a bit beyond my MySql kung-fu.

Granted - not a well formed idea, but basically it's get the processing away from php and into a nice efficient query....


-sean

Caching per user group would be another option then.

I think there's little to do about the fact you need that frick'n many pages in the menu, but reducing the load to only when the cache is cleared is quite easy to implement and will gain quick wins.

If your cache is cleared often, but the menu isn't, you could opt for using a non-resource partition to store the cached output, and use a plugin that trigged on the OnRefreshCache event (or something of that nature) - I think that only triggers when actually going to Site > Clear Cache. So the users could force the menu to be regenerated and beyond that it would remain static - though it would remain static by using a different cache for different user groups.


Like you say, it's only attacking the symptoms - not the content problem.

Hmmmm ... interesting, I didn't know that either cache option [by group or partition] was an option.

I've been trying to convince them for years to fix the content problem... so no, probably not going to happen.

I'm going to start digging now, but if you have links off hand, where can I start looking to find out about the per group caching option and how to store only the menu cache [cached menus?] on a 'non-resource partition'

-thanks
-sean

It's not an option, but easy to do with PHP.

Here's a quicky (adjusted copy/paste from a personal project):



And to clear it:


http://rtfm.modx.com/display/revolution20/Caching#Caching-ProgrammaticCaching
http://rtfm.modx.com/display/revolution20/modX.runSnippet

Note that that piece of code just takes the first user group it finds to check the cache.. if users are assigned to more than one it could be an unreliable way of checking the access. If users are only ever assigned to one it shouldn't be a problem I think.