ShowTable of Contents
Workplace Web Content Management caching, servlet caching (dynamic cache service), and pre-rendering are tools you can use to improve the performance of Workplace Web Content Management Web sites. Although pre-rendering is the fastest option, it has limitations.
Determining which cache to use
The following figure shows the caching options available from HTTP Server, WebSphere Application Server, and WebSphere Portal.
The shortest path shows that pre-rendering is the fastest option. However, the choice of which cache to use is not as easy as picking the fastest option.
Use the following set of considerations to decide which cache to use:
Consideration | Type of cache to use |
If the site is not using personalization and is not planned to use personalization in the future | Pre-rendering or Servlet Caching |
If the site is using a mixture of personalized and non-personalized content | Servlet caching if you want to cache only the non-personalized content.
Web Content Management caching solely, or a combination of it and servlet caching if you want to cache all content. |
If the site is using personalization or plans to use personalization in the future | Web Content Management caching |
Web Content Caching
If you decide to use Web Content Management cache, use the following additional set of considerations to determine the type of Web Content Management cache to use:
Consideration | Type of Web Content Management cache to use |
If the site is not using personalization and is not planned to use personalization in the future | Use "Basic" caching or the "Site" option of advanced caching, so that every user can access the same cached items. |
If the site content is personalized and unique for different groups of users | Use the "Secured" option of advanced caching, so users who have identical group configurations can access the same cached items. |
If the site content is personalized and content is unique for different personalization profiles | Use the "Personalized" option of advanced caching, so users who share the same personalization profile can access the same cached items . |
If the site content is unique for every user | Use the "User" option of advanced caching, so that all users gets their own cached items. |
If the site content is unique for every session | Use the "Session" option of advanced caching, so that every session gets its own cached items. |
Basic Caching
Basic Cache is the simplest form of WCM caching. The first time a Web page is rendered by the Web Content Management application, it is stored in a cache. Users then access this page from the cache until it expires. Only then is the Web page rendered afresh. The main benefit of this scenario is improved performance. Basic caching should only be used on static content that does not require "real-time" access.
Advanced Caching
Advanced caching provides more granular cache options. There are two major differences between basic caching and advanced caching:
- Advanced caching can cache pages based on different user profiles.
- Cache parameters in connect tags and URL requests can be used to override your server's default advanced Web content caching settings allowing you to set custom cache settings for individual Web pages or components
There 5 different types of Advanced caching that you can use:
- Site caching: This is the same as the basic Web content cache except that cache parameters in connect tags and URL requests can be used to override your server's default advanced Web content caching settings.
- Session caching: When session caching is enabled, a copy of each Web page a user visits is stored in the session cache. The User accesses the cached version of a Web page until they start a new session, or until the cached Web page is expired from the cache.
- User caching: When user caching is enabled, a copy of each Web page a user visits is stored in the user cache. The user accesses the cached version of a Web page until the cached Web page is expired from the cache.
- Secured caching: Secured caching is used on sites where the item security features are used to grant different users access to different Web pages and components based on the groups they belong to.
- Personalized caching: Personalized caching is used to cache Web pages of users who have the same "personalization profile". This means that users who have selected the same personalization categories and keywords, and who belong to the same group, share a single cache.
Configuring Advanced or Basic Caching
Configuring Advanced and Basic caching is a straightforward process. Refer to the Information Center for your version for details:
Version 6.1.x
Version 7.x
Custom Caching
You can overrule the default caching parameters of a site by using "cache" and "expire" parameters in URLs and IBM® Lotus Web Content Management tags. However,custom caching can only be used when a server's default Web Content cache is set to none or advanced caching. If basic caching is used as your default Web content cache, custom caching cannot be used.
With advanced caching enabled, you can use caching parameters within connect tags and URLs to:
- disable caching for the data being requested
- apply different caching parameters to the data being requested
This method is used with sites that are mostly static, but which contain a few dynamic elements that require a different caching strategy from the server's default caching strategy.
With no WCM caching enabled you can use caching parameters within connect tags and URLs to:
- enable caching for the data requested
This method is used with sites that contain a large number of elements requiring different caching strategies.
Using Custom Caching 6.1.x
Using Custom Caching 7.x
FAQ's about Web Content Caching
1. What cache instance does Basic caching use?
- Basic caching uses the services/cache/iwk/module instance. The Basic cache stores the entire response. The key is based only on the URL so all users will see the same response.
2. What cache instance does Advanced caching use?
- Advanced caching will use the services/cache/iwk/processing instance unless, you have chosen to use the Advanced Session caching. Then the
services/cache/iwk/session instance will be used.
3. If using WCM Advanced or Basic caching and I update a content item, will it be rendered?
- No. When using Advanced or Basic caching, the cache is not invalidated by content updates (not matter how it is done ie: authoring portlet, syndication WCM API, etc...). You will only see updated content when the cached item reaches it's expiry time. When the expiry time is reached, the new item will be retrieved from the internal WCM caches, where it was updated, and be re-cached in the external WCM cache.
4. How do I control when the caches expire?
- Items will be cached for the amount of time you specified when configuring Basic or Advanced caching. After that time has expired, the item will be removed from cache until it is accessed again and placed back into the cache. If you need to expire an item before the expiry time is reached, you can use the cache monitor describer in FAQ number 4.
5. How is the resourceserver.cacheExpiryDate parameter in the WCMConfigService.properties file related to WCM caching?
- The resourceserver.cacheExpiryDate property specifies the expiry date of resources cached by the resource server module. These resources are stored in the services/cache/iwk/processing cache instance. This cache stores the binary MIME for file and image resources in WCM. The maximum size of resources to store is also set in the WCMConfigService.properties file as the property resourceserver.maxCacheObjectSize (in kb). Resources over this size are not cached and are streamed directly to the response. The cache entry will be cleared when that resource is updated or when the expiry time is reached. This setting also controls the expiry time for the browser cache entry. By default resourceserver.cacheExpiryDate parameter is set to 1 month.
6. What are the default internal caches used for?
- The default internal caches are used by default and require no configuration to use. However, you may want to tune the internal caches as they will aid in overall performance. Here is a list of the default internal cache instances and what they are used for:
- services/cache/iwk/strategy – Item caching
This cache stores internal Lotus Web Content Management items. Any Lotus Web Content Management item read from the database will first check this cache. Lotus Web Content Management items cover Content, Workflow, Workflow Stages, Workflow actions, Taxonomies, Categories, Authoring Templates, Presentation Templates, Sites, Siteareas, and all Library Components. The cache entry will be updated or cleared when its corresponding Lotus Web Content Management Item is updated or deleted
- services/cache/iwk/objectsummary – Summary
This cache stores summaries of Lotus Web Content Management Items. The summaries are used to display in lists in the authoring portlet or used internally in the Lotus Web Content Management API to calculate Lotus Web Content Management Item Document IDs used for Iterators. The cache entry will be cleared when a Lotus Web Content Management Item is updated that will affect this summary.
- services/cache/iwk/menu - Menu
This cache stores Lotus Web Content Management Menu entries. An entry comprises of the Content IDs associated with a particular menu. The entries are retrieved and cached without applying security. Whenever a user needs that menu’s results, their specific security will then be applied to the cached results. A dynamic menu, which is one that is affected by the current user’s context (e.g. based on categories in a users profile) will store a separate cache entry for each different context. The cache entry will be cleared when a Lotus Web Content Management Item is updated that will affect this menu.
- services/cache/iwk/nav Navigator
This cache stores parent to child relationships that comprise a Lotus Web Content Management navigator. A complex navigator might have multiple parent to child relationships (e.g. if siblings are included). The navigator entry is made up of the IDs of the parent and children. This cache will be cleared upon any Lotus Web Content Management Item update in the system.
- services/cache/iwk/abspath – Absolute path
This cache stores JCR path to ID relationships. The cache entry will be cleared when a Lotus Web Content Management Item is updated that will affect it.
- services/cache/iwk/missed – Missed Items
This cache stores JCR paths that does not exist. This is used primarily for multi locale solutions to determine if items of other locales exist or not. The cache entry will be cleared when a Lotus Web Content Management Item is updated that will affect it.
- services/cache/iwk/global - Library
This cache contains a lookup for library ID, name and path to the library object. This is pre-populated up to the cache size at Portal startup.
- services/cache/iwk/libparent – Library Parent
This cache stores a list of all children library IDs to a given parent ID. Introduced for Quickr to group libraries within a teamspace together.
- services/cache/iwk/draftSummary – Draft Summary
This cache stores the identity of the draft summary to the identity of the draft Lotus Web Content Management Item.
- services/cache/iwk/session - Session
This cache stores the page data for when session advanced caching is enabled. See the InfoCenter for enabling Lotus Web Content Management Advanced caching.
- services/cache/iwk/processing – Advanced and Resources
In addtion to being used by Advanced cache, this cache stores the binary MIME for file and image resources in Lotus Web Content Management. The maximum size of resources to store is set in the WCMConfigService.properties file as the property resourceserver.maxCacheObjectSize (in kb). Resources over this size are not cached and are streamed directly to the response. The expiry is set in the same file as: resourceserver.cacheExpiryDate. The cache entry will be cleared when that resource is updated.
Servlet Caching (Dynamic Cache Service)
Servlet caching involves caching the request at the WebSphere Application Server layer. This type of caching is not as fast as pre-rendering, but it is faster than Web Content Management caching and, depending on your needs, can be more flexible.
Although servlet caching cannot cache personalized content, it can be used to selectively cache or not cache individual pages. Depending on the type of rendering that is used, servlet caching can be enabled to either cache the results of portlets or the Web Content Management servlet.
When using with servlet-rendering (this is not required for the rendering portlets), it’s recommended the specific ‘component’ entry below be added to disable Servlet-Caching for Web Content Management’s Utility Modules and Syndication, as caching these elements will break both the Utility Modules and Syndication:
<cache-id>
- Normal ‘component’ sections describing what to cache
<component id="MOD" type="parameter">
<required>false</required>
<not-value>Subs</not-value>
<not-value>Synd</not-value>
<not-value>ItemDispatcher</not-value>
<not-value>Syndication</not-value>
<not-value>MemberFixer</not-value>
<not-value>VersioningEnablement</not-value>
<not-value>WorkflowEnablement</not-value>
<not-value>PlutoUploadFile</not-value>
<not-value>PlutoDownloadFile</not-value>
<not-value>AJPECatSelect</not-value>
<not-value>RefreshAllItems</not-value>
<not-value>Template</not-value>
</component>
</cache-id>
<cache-id>
- Normal ‘component’ sections describing what to cache
<component id="MOD" type="parameter">
<required>false</required>
<not-value>Subs</not-value>
<not-value>Synd</not-value>
<not-value>ItemDispatcher</not-value>
<not-value>Syndication</not-value>
<not-value>MemberFixer</not-value>
<not-value>VersioningEnablement</not-value>
<not-value>WorkflowEnablement</not-value>
<not-value>PlutoUploadFile</not-value>
<not-value>PlutoDownloadFile</not-value>
<not-value>AJPECatSelect</not-value>
<not-value>RefreshAllItems</not-value>
<not-value>Template</not-value>
<not-value>ClearVersions</not-value>
<not-value>ClearHistory</not-value>
<not-value>Custom</not-value>
<not-value>Data</not-value>
<not-value>UnlockLibrary</not-value>
<not-value>ResetEventLog</not-value>
</component>
</cache-id>
It’s additionally recommended the specific ‘component’ entry below be added to allow requests with CACHE=NONE in the query string to bypass the cache:
<cache-id>
- Normal ‘component’ sections describing what to cache
<component id="CACHE" type="parameter">
<required>false</required>
<not-value>NONE</not-value>
</component>
</cache-id>
Servlet caching limitations
- Servlet caching must be re-enabled after a fix pack or cumulative-iFix is applied. Keep a backup of your cachespec.xml file, so you can easily re-enable servlet caching.
- Restart the server after making changes to the cachespec.xml file.
- When specifying "pathinfo" components in a cache-id, include the Web Content Management library name in any "non-value" and "value" attributes. Additionally remove any "+" characters from the URLs.
- Error responses from the portlets and servlet are cached (such as file not found and exceptions), which is typically not expected and can cause problems in documents are removed from the live website temporarily.
- Specifying a URL to a site or site area in either the "non-value" or "value" attributes does not also specify the site or site area's children. The only way to do selective caching is to either:
- Use the "non-value" attribute to specify the URL of every page that should not be cached.
- Use the "value" attribute to specify the URL of every page that should be cached.
- For non JSR-286 rendering portlets, the default context of the portlet cannot be cached.
- For non JSR-286 rendering portlets, if alternate page design is enabled after caching, then the design will not display until after the cache is cleared.
Additional Servlet caching limitations with Servlet Rendering
- When using dynamic cache service with servlet rendering, be careful not to overwrite the existing cachespec.xml file. Add your cache-id sections after the existing one.
- Unlike for rendering portlets, when using servlet rendering caching, if the following arguments are not specified in the cache-id, then the following behavior is observed
Argument | What happens if it is not specified |
id | Dynamic cache service does not distinguish between Draft and Published copies of the same object. |
pagedesign | Dynamic cache service does not distinguish between the default and alternate pagedesigns of the same content. |
version | Dynamic cache service does not distinguish between the current and previous versions of the same object. |
source | Library and content components do not render under some conditions. |
cmpntname | Library and content components do not render under some conditions. |
cmpntid | Library and content components do not render under some conditions. |
How to configure servlet-caching
How to configure servlet-caching for the JSR-286 local rendering portlet
See this
page for information on using servlet-caching with the JSR-286 rendering portlet
How to configure servlet-caching for the local rendering portlet
1. Ensure that the dynamic caching service is enabled for the WebSphere Application Server.
2. Define what is and is not cached in your cachespec.xml file.
3. Use the following commands to backup, then update the Local-Rendering portlet:
- From a command-prompt, navigate to [WPS_ROOT]\installableApps
- Copy ilwwcm-localrendering-portlet.war to ilwwcm-localrendering-portlet.war.backup
- Make a new directory called wcm_lrp_war and navigate to it.
- Run the following command:
- [WAS_ROOT]/java/bin/jar –xf ../ilwwcm-localrendering-portlet.war
- Copy your cachespec.xml file to [WPS_ROOT]/installableApps/wcm_lrp_war/WEB-INF
- Run the following command:
- [WAS_ROOT]/java/bin/jar –cf ../ilwwcm-localrendering-portlet.war *
4. Use the WebSphere Portal Administration page to re-deploy any modified portlets from the [WPS_ROOT]\installableApps directory.
5. [Optional] Install the dynamic cache monitor on the WebSphere Application Server.
NOTE: Steps 3-4 will need to be repeated whenever a fixpack OR cumulative iFix is applied, so you should keep a backup of your cachespec.xml file for this purpose
How to configure servlet-caching for the remote rendering portlet
1. Ensure that the dynamic caching service is enabled on the WebSphere Application Server.
2. Define what is and is not cached in your cachespec.xml file for the WebSphere Application Server.
3. Use the following commands to backup, then update the Remote Rendering portlet:
- From a command-prompt, navigate to [WPS_ROOT]\installableApps
- Copy ilwwcm-remoterendering-portlet.war to ilwwcm-remoterendering-portlet.war.backup.
- Make a new directory called wcm_rrp_war and navigate to it.
- Run the following command:
- [WAS_ROOT]/java/bin/jar –xf ../ilwwcm-remoterendering-portlet.war
- Copy your cachespec.xml file to [WPS_ROOT]/installableApps/wcm_rrp_war/WEB-INF
- Run the following command:
- [WAS_ROOT]/java/bin/jar –cf ../ilwwcm-remoterendering-portlet.war *
4. Use the WebSphere Portal Administration page to re-deploy the modified portlets from the [WPS_ROOT]\installableApps directory
5. [Optional] Install the dynamic cache monitor for the WebSphere Application Server.
NOTE: Steps 3-4 will need to be repeated whenever a fixpack OR cumulative iFix is applied, so you should keep a back up of your cachespec.xml file for this purpose
How to configure servlet-caching for servlet rendeing
1. Ensure that the dynamic caching service is enabled for the WebSphere Application Server.
2. Define what is and is not cached in y our cachespec.xml file.
3. Use the following commands to backup, then update the WCM ear file:
- From a command-prompt, navigate to [WPS_ROOT]\wcm\installableApps
- Rename wcm.ear to wcm.ear.backup.
- Run the following command:
- [WAS_ROOT]/bin/earexpander.bat –ear wcm.ear –operationDir ./wcm_ear –operation expand
- Merge your cachespec.xml file with the one already existing in ./wcm_ear/ilwwcm.war/WEB-INF.
- Do not overwrite the existing cachespec file.
- Run the following command:
- [WAS_ROOT]/bin/earexpander.bat –ear wcm .ear –operationDir ./wcm_ear –operation collapse
- Run the following Portal Config command to redeploy the updated wcm.ear file:
- [WPS_ROOT]/config/WPSconfig.bat update-wcm-ear
4. [Optional] Install the dynamic cache monitor on the WebSphere Application Server.
NOTE: Steps 3 will need to be repeated whenever a fixpack OR cumulative iFix is applied, so you should keep a backup of your cachespec.xml file for this purpose
Servlet-Caching examples
Note: See this
page for JSR-286 rendering portlet examples
Rendering Portlet Examples
- Cache everything for 300 seconds:
<cache>
<cache-entry>
<class>servlet</class>
<name>/jsp/html/view.jsp</name>
<property name="store-cookies">false</property>
<property name="consume-subfragments">true</property>
<cache-id>
<component id="WCM_GLOBAL_CONTEXT" type="parameter">
<required>true</required>
</component>
<timeout>300</timeout>
</cache-id>
</cache-entry>
</cache>
- Cache everything except for ‘/wps/wcm/connect/MyLibrary/MySite/MySiteArea/MyContent’ and ‘/wps/wcm/connect/MyLibrary/MySite/MySiteArea/MyContent2’:
<cache>
<cache-entry>
<class>servlet</class>
<name>/jsp/html/view.jsp</name>
<property name="store-cookies">false</property>
<property name="consume-subfragments">true</property>
<cache-id>
<component id="WCM_GLOBAL_CONTEXT" type="parameter">
<required>true</required>
<not-value>/wps/wcm/connect/MyLibrary/MySite/MySiteArea/MyContent</not-value>
<not-value>/wps/wcm/connect/MyLibrary/MySite/MySiteArea/MyContent2</not-value>
</component>
<timeout>300</timeout>
</cache-id>
</cache-entry>
</cache>
- Cache only ‘/wps/wcm/connect/MyLibrary/MySite/MySiteArea/MyContent’ and ‘/wps/wcm/connect/MyLibrary/MySite/MySiteArea/MyContent2’:
<cache>
<cache-entry>
<class>servlet</class>
<name>/jsp/html/view.jsp</name>
<property name="store-cookies">false</property>
<property name="consume-subfragments">true</property>
<cache-id>
<component id="WCM_GLOBAL_CONTEXT" type="parameter">
<required>true</required>
<value>/wps/wcm/connect/MyLibrary/MySite/MySiteArea/MyContent</value>
<value>/wps/wcm/connect/MyLibrary/MySite/MySiteArea/MyContent2</value>
</component>
<timeout>300</timeout>
</cache-id>
</cache-entry>
</cache>
Servlet Rendering Examples
- Cache everything for 300 seconds:
<cache>
<cache-entry>
<class>servlet</class>
<name>com.presence.connect.ConnectServlet.class</name>
<property name="store-cookies">false</property>
<property name="consume-
subfragments">true </property>
<cache-id>
<component id="" type="pathinfo">
<required>true</required>
</component>
<component id="source" type="parameter">
<required>false</required>
</component>
<component id="cmpntname" type="parameter">
<required>false</required>
</component>
<component id="cmpntid" type="parameter">
<required>false</required>
</component>
<timeout>300</timeout>
</cache-id>
</cache-entry>
</cache>
- Cache everything except for ‘/MyLibrary/MySite/MySiteArea/MyContent’ and ‘/MyLibrary/MySite/MySiteArea/MyContent2’:
<cache>
<cache-entry>
<class>servlet</class>
<name>com.presence.connect.ConnectServlet.class</name>
<property name="store-cookies">false</property>
<property name="consume-subfragments">true</property>
<cache-id>
<component id="" type="pathinfo">
<required>true</required>
<not-value>/MyLibrary/MySite/MySiteArea/MyContent</not-value>
<not-value>/MyLibrary/MySite/MySiteArea/MyContent2</not-value>
</component>
...........
<component id="cmpntid" type="parameter">
<required>false</required>
</component>
<timeout>300</timeout>
</cache-id>
</cache-entry>
</cache>
- Cache everything for 300 seconds, differentiate between draft and published:
<cache>
<cache-entry>
<class>servlet</class>
<name>com.presence.connect.ConnectServlet.class</name>
<property name="store-cookies">false</property>
<property name="consume-subfragments">true</property>
<cache-id>
<component id="" type="pathinfo">
<required>true</required>
</component>
...........
<component id="cmpntid" type="parameter">
<required>false</required>
</component>
<component id="id" type="parameter">
<required>false</required>
</component>
<timeout>300</timeout>
</cache-id>
</cache-entry>
</cache>
Pre-Rendering
Considerations / Limitations
The following considerations / limitations need to be observed when using Pre-Rendering and could mean that the site can’t or isn’t applicable for pre-rendering in worse cases:
- No personalisation: As pre-rendering takes a snapshot of the WCM repository and all users see the same content, a site that is personalised can’t be pre-rendered. If it is pre-rendered then every user will see the content that the chosen pre-renderer user is profiled to see
- Workaround: Use client-side aggregation to call the WCM servlet to lazy render items requiring personalization
- Long Filenames: The path to the Content item (including the directory path you are pre-rendering to - Site/SiteArea/Content ) can not exceed the operating system's maximum path length:
- 255 characters in Microsoft Windows.
- 1024 characters in Linux.
- Invalid Characters in Site, Site Area or Content Names: Sites, Site Areas, and Content obejcts can not contain characters that are considered invalid in filenames by the operating system you are pre-rendering to. E.g. - In a Microsoft Windows environment, these characters are invalid: / \ : * ? " < > |
- Limited security: Although you can tell the pre-rendering which user to use when generating the snapshot (so the snapshot only contains what they can see), once the snapshot is taken, your security options are limited by what features your HTTP server has
- Long time to take snapshot: It can take a long time to pre-render a site and while the site is being pre-rendered, users will be locked out of the system
- Entire site must be pre-rendered before it can be used: The entire site must be pre-rendered before it can be used, otherwise users will get broken links
- Links to PDM documents: If your content contains links to PDM documents, then this links will be rendered intact, so the final HTTP Server will need access to the PDM server in order for those links to work
- Can’t use WCM Search
- Note: Third Party Search Crawlers OR IBM Omnifind ok!
- Can’t use Page Navigation Components: Page navigation components aren’t be pre-rendered due to their dynamic nature
- No JSP component support prior to WCM 6.1 CF39 and WCM 7.0 CF7
Optimizing performance
- Use a dedicated Pre-Rendering Server and set the ‘connect.moduleconfig.cacher.busydelay’ setting to the same value as the ‘connect.moduleconfig.cacher.delay’ setting
- If the Pre-Rendering Server’s hardware can handle it, you could change the ‘connect.moduleconfig.cacher.delay’ and ‘connect.moduleconfig.cacher.busydelay’ delay settings to 0 to indicate no delay between pre-rendering pages.
- Follow the recommendations in the Performance section to tune the Pre-Render Server
PreRendering a single page
If you need to pre-renderer a single page, than rather than using WCM pre-renderering feature, which is designed to pre-render entire sites, use the Linux wget command or equivalent to periodically fetch the page directly from WCM, which will return the flat HTML version of the page which can then be saved to your web-server.. Within your WCM website, replace any links to the pre-rendered page with the link to the web servers flat version.
Troubleshooting Pre-Rendering
If you are having issues with pre-rendering please review the following article:
Troubleshooting Web Content Management Pre-rendering
Flushing and Monitoring caches
To flush or monitor the caches, you will need to install the Dynacache Cache Monitor that comes with AppServer (cachemonitor.ear), then install the 'Extended Cache Monitor' (
http://www.ibm.com/developerworks/websphere/downloads/cache_monitor.html) over the top..
The caches (which you will then see in the Cache Monitor) are as follows:
- Servlet Caching > BaseCache
- WCM Basic Cache > services/cache/iwk/module
- WCM Advanced Cache > services/cache/iwk/processing
- WCM Session Cache > services/cache/iwk/session
Comments and Discussions:
A new thread has been created on the WCM Forum to enable further comments and discussions:
https://www.ibm.com/developerworks/forums/thread.jspa?threadID=277044