Rules for WCM Menus:
0. Look at the WCM Wikis for tuning advice.
1. Keep WCM menus small (10 items or less)
2. Use WCM pagination if you must do pagination (as opposed to rendering a large menus and paging the results via JQuery on the browser)
3. Don't use an excessive number of menus (3 or more) per Portal page
In terms of CPU path length, perhaps the most expensive WCM component that you can use is the menu. However, the menu component is often the best component to use in WCM since it allows you to select and render the WCM content best suited for this user.
WCM designers love the menu! And they should. The menu is an elegant and flexible tool which allows the designer to pick WCM content that matches several criteria. A menu
is ultimately a search mechanism that groups together
related documents based on specific criteria such as categories, keywords,
authoring templates, site areas, and so forth. It then allows that content to be displayed to the user in what ever fashion HTML allows. Menus will be used!
This blog entry discusses WCM menu and designing for performance. The dark truth is that menus are expensive. The rendering of a menu, especially with empty WCM caches, taxes the JCR database domain because WCM needs information about:
1. The menu itself
2. The meta-data associated with the content items in the menu
3. Permission information (Portal Access Control, a.k.a. PAC) associated with each content item.
All this information is persisted in the database. In many cases, WCM makes queries to the database in the form of XPATH (XML query language) transformed into SQL. If you've ever looked at the XPATH based SQL that WCM generates, it is quite long (100-200 characters is not uncommon). It also has join statements that work the database engine hard. The generated dynamic SQL is difficult to cache on on the DB server. If a menu is large, it is easy to see how how the SQL can tax the database engine. The query optimizer can make poor choices as to the best execution plan for WCM (JCR) XPATH.
The bottom line, especially for the initial render of a menu item (e.g. caches are empty) is that it can take a long time to render a WCM menu. So, how do we make WCM menu renders fast given that we need them??
0. Start with the WCM Tuning Wiki
The WCM Wiki's contain useful information about designing WCM components for performance. For menus, take a look at: http://www-10.lotus.com/ldd/portalwiki.nsf/dx/tuning-for-web-content-management#Optimising+Menu+Components.
1. Make the menus small.
If the menu component only retrieves a few content items, it doesn't have to hit the database much. This means that the time spent to render the menu is small if the caches are empty and the database must be hit.
As an aside, you find that even large menus are pretty fast if the caches are already loaded. So, one option if the menu must be large is to keep the meta-data caches primed by hitting the page(s) in question with a tool like JMeter.
2. Paginate the menus using WCM if they must be large.
If WCM pagination is used, and the actual page render size per trip is small (let's say 100 total items in the menu with only 10 items rendered per trip to the server), the WCM designer still benefits from better performance of the menu being small. Hopefully, the probability is high that what the user actually needs exists on the first render. If not, perhaps the Information Architecture of the page is in question and should be revisited. Either way, WCM pagination should be used if the menu results are large if left unbounded.
3. Make the Access Control as liberal as possible.
When a menu is rendered by WCM, it is actually a two step process. First the menu is calculated without respect to the access control constraints of the user or the content. This is so that the "menu cache" can be calculated and stored. Then these results in the menu cache are compared to the access control constraints of the content returned by the menu to the allowance of the user. From this, the final menu results can be returned to the user's browser. So, the initial menu calculation (stored in the "menu" cache) are done without regard to any one user's access control constraints.
Therefore, it seems obvious that the speed with which a persons access control can be calculated is important.
Access Control in Portal comes from the groups with which person belongs. Content is stored with the groups, taxonomies and categories with which a person is allowed. With respect to WCM performance, there is a hierarchy of least expensive to most expensive. The most efficient form of access control is "none". The most expensive form is to places access control on each piece of content with lots of groups and have users that belong to lots of unique groups. There is usually a middle ground for both users and content that can help. The person responsible for the WCM Information Architecture should be familiar with "design for performance" of WCM and able to guide the client in picking the best access control
Also, it is more efficient for content (menu or not) to inherit access control as opposed to each content item having unique access control. If at all possible in your Information Architecture, use WCM access control inheritance.
General Menu Considerations:
This comes from the WCM Wiki (http://www-10.lotus.com/ldd/portalwiki.nsf/dx/tuning-for-web-content-management#Optimising+Menu+Components)
- Avoid too many search criteria (in 'Menu Element Query' section)
utilising the options in the 'Further options' section for each
criteria unless really necessary, as this stops the menu from being
- For Category and/or Site Area restricted
menus, only select both 'Ancestors' and 'Descendants' if really
necessary and limit the number of categories and site areas specified
- Disable sorting by 'Description' unless really required (set the value to one of the other sort fields to disable)
- For unsecured sites (where content is accessed anonymously or always
accessed by the same user, eg. Administrator), set 'Maximum pages to
include' and 'Pages to read ahead' to 1
- If using multiple
libraries, ensure that at least 1 site area is selected in each menu
otherwise the menu will search against all libraries
should not be used to return a flat list of all content in the system
for providing to a search engine, this is what the search seed is for.
Where this is unavoidable, a paging component must be used to ensure
that the menu does not consume too much memory and thus cause memory