Web Content Manager performance can be improved by enabling caching. In fact we recommend to enable caching for WCM for production sites. There are multiple caching options with WCM.

Fragment caching allows to cache data for a single user or across all users for a WCM rendering portlet.

WCM Advanced caching caches WCM data at the WCM core level - below the WCM portlets. It is flexible - 5 different cache configurations are possible. The most common used option typically is Secured caching in which the cache key is computed based on the group membership of the user.

The downside of WCM Advanced caching is that you can not control that for certain WCM rendering portlets no cache is being used since the caching happens below the portlets. The reason why you might want to disable Advanced caching for certain WCM rendering portlets could be that some data in them has to be immediately visible or that the portlet displays WCM content that uses PZN rules (PZN rule results would be cached and the rule not executed any more).

Using fragment caching in the WCM portlets can be an alternative to
Advanced caching but it does not allow to use Secured caching or the
other caching options of WCM Advanced caching - it only allows to have a
shared cache across all users or a personal cache for each user.

I have implemented a preprocessor that can be configured per WCM rendering portlet to disable the WCM data in this portlet from being cached in the Advanced cache. The attachment below points to a zip file containing a war file. To use the preprocessor deploy the war file with an arbitrary context root via the WebSphere Application Server Admin Console and start the Application. The source code is attached in the war and can be modified. Then edit the WCM rendering portlet configuration and select the now visible preprocessor "NoCachePreProcessor" - save the portlet.

See the usual DISCLAIMER OF WARRANTIES: The enclosed code is sample code created by IBM Corporation.This sample code is provided to you solely for the purpose of assisting you in the development of your applications. The code is provided "AS IS", without warranty of any kind. IBM shall not be liable for any damages arising out of your use of the sample code, even if they have been advised of the possibility of such damages.

Stay tuned for another blog entry about how to customize the cache key of the Advanced WCM Cache.

An important caching technology to ensure good performance in WebSphere Portal is fragment caching. Portlet html fragments are cached for reuse for subsequent requests.

Due to an issue with the install scripting in Portal 7 and 8 fragment caching on any secondary nodes in a cluster was not working. This issue was fixed with CF15 for WebSphere Portal 7.0.0.1 and 7.0.0.2 and CF1 for Portal 8. If you created the secondary node(s) though before having the fixes applied fragment caching on secondary node(s) will not work.

To verify if you are having the issue - check if the file cachespec.xml exists in the <profile>/properties directory on the secondary node(s). If the issue exists on your system and you are using fragment caching you should copy the file from the primary node and restart to fix the problem. To verify that the issue is solved you can leverage the WebSphere Application Server Extended Cache Monitor. After installing it, check the base cache to ensure that fragment cache entries are inside the cache after hitting a page that has portlets that use fragment caching. A sample entry could look like this:

A common problem that customer's often face is having a large Portal cluster in one part of the world, but having to access it from another. Because of the large number of "GET" requests needed to render a Portal page along with the latency of transcontenental access, performance typically suffers.

One way to alleviate this latency issue is by caching the "statics" required to render a Portal page. Generally, only one of these 1 GET requests is required to render a Portal page needs to be calculated dynamically by the Portal server. The rest are typically CSS, Javascript and images that are invarient. These invarient statics could be rendered from a cache if available. By caching these statics locally (e.g. with low latency), one can greatly reduce Portal render times on average.

In addition, the WebServer in EMEA would impliment a caching proxy as a part of the reverse proxy cache. So, the client brower would access the site via the EMEA WebServer. That EMEA webserver would serve content from it's local cache as able. If the content is not in the local cache, it would forward the request to the USA WebServer. Note that this would always happen for the base Portal page as well as any statics not already in the EMEA cache.

Instead of using the address of the server(s) in the USA, the EMEA customer would now request the page via the hostname of the EMEA WebServer. Something like this:

Users could either use the new hostname (as immediately above), or the DNS server in their geography could return the EMEA webserver instead of the USA version of it. The later would make this local proxy server strategy transparent to the user.

The EMEA Apache web server would use this in it's httpd.conf to proxy the request to the USA webserver:

For effective, efficient and scalable portlet design, the mantra is cachability. Portal and WCM are all about caching. Without caching, Portal and WCM cannot and will not scale.

Given that view, this entry discusses optimal portlet design. Optimal, in this case, means "cache as much as possible and only personalize as you must and as late as possible".

With that perspective, the answer is straightforward. Try to design portlets so that the markup is common to all users in the portlet and anything unique to a user is delivered via AJAX at browser render time.

If done this way, the portlet is very cachable. One can imagine that the doView and JSP that render a portlet deliver the same HTML to all users as well as the same CSS (if needed) and Javascript. Since this is all the same content for every user, the portlet is cachable. It is thus available for portlet caching. Portlet caching is a technique in Portal to greatly speed up renders and scalability.

Once this portlet is delivered the client browser, the browser can make AJAX calls to get the content that is specific to that user, populate the rest of the DOM and complete the render. These AJAX calls are authenticated and so security is preserved and only information destined to a particular user will be rendered.