Portlet Features
The next sections discuss some of the portlet-tuning features available with WebSphere Portal that should be considered by developers, and could influence the implementation technique chosen. Some required settings have to be provided with the portlet's deployment descriptor, and since these items are also supplied by a portlet developer, they're considered custom code.

Enabling Portlets for Parallel Rendering
WebSphere Portal offers the option of having portlets on a page rendered in parallel. This feature isn't completely "for free" because computing resources are required to maintain and manage the different threads that are used to render each single portlet.

Parallel portlet rendering can be advantageous in cases where many backend systems are involved that produce their own latency while rendering a single page. For example, consider a portal page that contains a number of portlets, each of which accesses a different backend system. In serial rendering mode, the overall latency for retrieving the required data from all the backend systems would have to be calculated as the sum of the individual latency times. In parallel rendering mode, the latency would be the maximum of all individual latency times.

If portlets don't use a backend system too often, the overhead for enabling parallel portlet rendering can become greater than the benefits gained from this feature. If portlets on a page can be rendered independently of a backend system, they only need CPU resources local to the portal server machine. In this case, the page render response time won't be improved.

Parallel portlet rendering can be enabled for each portlet separately with the graphical UI, or with the deployment descriptor, or with WebSphere Portal's XML access interface. On top of that, there's a global property value that generally turns parallel portlet rendering on and off.

To properly answer the question of whether or not to enable parallel portlet rendering for a portal, there are several things to consider; for example, the number of backend systems involved for rendering a page, typical page structure, the average number of portlets on a page that exploit parallel portlet rendering, and so on. Such questions may not necessarily be answerable in advance by a portlet developer, but certainly the developer can make sure that a portlet is enabled for parallel portlet rendering if that makes sense up-front.

Caching in the Portlet Container
Portlet-based Web pages are aggregated dynamically because of their ability to deliver dynamic content in a personalized manner. This flexibility comes at a cost. Web site response time increases because of the additional work that has to be done to generate these pages on request.

New caching technologies improve the performance of dynamic page generation and reduce system load. WebSphere Portal supports fragment caching (also known as servlet caching) using the WebSphere Application Server dynamic cache to keep portlet output in the cache. Requests for a cached portlet retrieve the content from the cache instead of the portlet. The invalidation of the fragment cache can be accomplished by specifying the expiration time in the deployment descriptor. Further, the fragment cache entries are invalidated during the action phase of the portlet.

There's no time-consuming installation and integration work needed to activate fragment caching. The cache is enabled and disabled using simple XML deployment descriptor files and the WebSphere Application Server administrative console. (See the WebSphere Portal Information Center for details on enabling servlet caching in WebSphere Application Server.)

To make use of expiration-based caching, portlets must define the duration of the expiration cache in the deployment descriptor portlet.xml (for standardized portlet following JSR 168 specification):

<expiration-cache>300</expiration-cache>

A positive number defines the number of seconds a cache entry exists in the cache.

• A value of -1 indicates that the portlet cache never expires.
• A value of 0 indicates that caching is disabled for the portlet.

For a JSR 168 portlet that has defined an expiration cache in its deployment descriptor, the portlet window can modify the expiration time at runtime by setting the EXPIRATION_CACHE property in the RenderResponse as follows:

renderResponse.setProperty(
   RenderResponse.EXPIRATION_CACHE,
   String.valueOf(numberCrunchingCalculation())
);

Fragment caching isn't useful for portlets that are truly dynamic in nature; for example, real-time-based portlets that have to collect current data from other data sources on each request, or portlets that change their response markup on every request. This would result in a high number of cache invalidations and hence there would be no gain in performance. Therefore, the portlet should be enabled for caching only if the output of the portlet will be valid for some period of time before it's updated.

Caching in Remote Caches
With the unique adaptive page-caching feature, WebSphere Portal offers the possibility of dynamically caching generated pages in caches external to a portal server (so-called remote caches), if all the page components indicate that they're cacheable. If completely rendered pages are served from remote caches, a roundtrip to the portal server can be avoided and response times for such pages can potentially be as fast as if they were served from static Web sites.