Parallel portlet rendering

Overview

Configure parallel portlet rendering to optimize the response time. When portlets on a page are rendered sequentially, some portlets can delay output from other portlets to the client browser. Enable parallel portlet if a high proportion of the portlets access remote locations to fetch the content that they render, for example by consuming WSRP services as remote portlets from a WSRP Producer.

Parallel portlet rendering is intended for server-side rendering only. It is not supported for client side rendering with the Page Builder theme.

For portlets to be rendered parallel, the settings for both the portal and the individual portlets need to be set to enable parallel portlet rendering.

The default setting for the portal is that portlets cannot be rendered in parallel. In addition, the default setting for individual portlets is not to be rendered in parallel. An individual portlet needs to be enabled for parallel rendering, for example, by the portlet developer or the administrator. Therefore, if you enable the portal wide property for parallel portlet rendering, the portal renders only those portlets concurrently which have been configured accordingly. Portlets that are not enabled for parallel rendering are always rendered sequentially.

Set a portlet for parallel rendering

To enable parallel rendering for a portlet...

Portal Administration | Portlet Management | Portlets | portlet | Configure (wrench) | Enable parallel rendering

Alternatively to enable parallel rendering of an IBM portlets, or as a read-only preference in standard portlets....

parallel = true|false

Usually only some of the portlets that are configured for parallel rendering are actually rendered in parallel. Portlets for which the portal cannot provide a thread immediately are rendered sequentially. Therefore, in order to get the best performance, select carefully which portlet you configure for parallel rendering.

Set portal for parallel rendering

You can change the portal wide settings for parallel portlet rendering in the PortletContainerService. You use two different parameters for configuring parallel portlet rendering, depending on the type of portlets (JSR standard or IBM) you want to have rendered parallel:

• For parallel rendering of local IBM portlets, set...
  legacy.useParallelRendering.markup = (false)
  Activates the portlet container functionality for parallel portlet rendering for the specified markup. Valid values are true or false . By default this parameter is set to false . If you omit the markup, the setting applies to all markups for which no specific setting has been defined.

• For parallel rendering of local JSR portlets, or for remote portlets that you integrated in a WSRP Consumer portal, set...
  std.useParallelRendering.markup = (false)
  Activates the portlet container functionality for parallel portlet rendering for the specified markup. Valid values are true or false. By default this parameter is set to false . If you omit the markup, the setting applies to all markups for which no specific setting has been defined.

Settings for configuring the parallel portlet rendering parameters...

false	Parallel rendering is disabled. Default. All portlets are rendered sequentially, even if they are enabled for parallel rendering.
true	Parallel rendering is enabled. All portlets which have parallel rendering enabled are rendered in parallel. Portlets that are not enabled for parallel rendering are rendered sequentially.

Fine tuning parallel portlet rendering

These parameters apply to both main parallel portlet rendering parameters given above.

parallelRenderingTimeOut = (2000)	Timeout in milliseconds after which the render process of a portlet is stopped. The default is 2000 milliseconds (= 2 seconds).
parallelRenderingTransferTimeOut = (2000)	Timeout in milliseconds after which the main thread stopss transferring the portlet content from the parallel pipe to the main response. The default is the value specified by the parallelRenderingTimeOut setting above.
parallelRenderingWaitTimeOut = (1)	Waiting time in milliseconds for parallel threads to finish the render process of portlets. The default is 1 millisecond. A low value can result in exceptions caused by portlets that could not finish their parallel rendering process. A high value can cause an increase of the response time. The value 0 (zero) specifies that no timeout occurs and the main thread waits for all portlets to finish. Queues are used to pass the content of the portlet between the threads. You can configure the queue handling by setting the following parameter:
parallelRenderingChunkSize = (1024)	Size of the chunks in bytes that are read from the queue. The default value is 1024 bytes.

All queues are held in a pool for reuse. You can change the pool settings for parallel portlet rendering in the pipe pool. For more details refer to the documentation about the pipe pool under portal configuration services.

Asynchronous beans are used for the parallel rendering process. A WorkManager wm/wpsWorkManager is configured to manage the asynchronous beans. Do not change this name as the name is set in both the WAS and the WebSphere Portal configurations. Set the option isGrowable in the WorkManager panel of the WAS to false. Otherwise parallel portlet rendering might not work to the full extent.

For optimal operation of parallel portlet rendering, the number of threads used by the work manager should be adjusted to system resources and the requirements of system and users. System resources are important as each additional thread requires additional memory. The requirements for proper operation can be monitored using the WAS Performance Viewer. In the Performance Viewer you can determine whether the thread pool used by the work manager is sized appropriately. In the thread pool, increase the maximum number of threads if all threads are constantly in use. In addition, verify the 'Work request queue size' setting for the work manager. Portlets are rendered in parallel only if their requests can be queued by the work manager before execution. If the queue is full, threads will not be rendered in parallel. This parameter cannot be monitored. The specified default provides a good starting point for most environments.

When general tracing is enabled and parallel portlet rendering is turned on, portlets that are configured to be rendered in parallel display the render time as part of the portlet content. To use general tracing but do not want the render times to be displayed for such portlets, selectively disable tracing for...

com.ibm.wps.pe.PortletRenderTimeLoggingHelper

Enabling parallel rendering makes sense only for markups that can display all portlets on a page, such as HTML. Do not enable parallel rendering for markups that can only display a single portlet of a page at a time, such as WML.

How to prepare portlets for parallel portlet rendering

In general, all portlets must be implemented in a thread-safe manner to be accessible by multiple users at the same time. The portlets can then be rendered in parallel. However, you need to be aware of the following specific limitations for portlets to render in parallel:

• In general, do not use any non-public APIs or APIs that are not documented for use in portlets, such as engine tags with portlets. The public APIs are defined in the WebSphere Portal Java documentation.

• Portlets that are rendered in parallel must not access any non-threadsafe objects that are scoped to the servlet request:

  • In general, thread safety of the objects is documented in the Java documentation. Examples of non-threadsafe objects are all unsynchronized Java collections and org.apache.jetspeed.portlet.User.

  • The portlet request that is passed to portlets that are rendered in parallel is threadsafe and all methods that are part of the portlet API can be safely used. However, the underlying servlet request is not threadsafe.

• Portlets that are rendered in parallel, like any other defensively implemented portlets, should be prepared to handle IOExceptions when writing to the OutputStream or PrintWriter of the PortletResponse: Depending on the configuration settings for parallel portlet rendering, if a portlet takes too much time for rendering its content, the portal can cancel rendering this portlet. When the portlet tries to write to the OutputStream or PrintWriter after the portal has canceled the rendering, this results in an IOException. In this case the behavior is the same as if the user closes the browser before the resulting page is delivered to the client. The portlet should take care of proper error handling for this situation.

• Portlets that are rendered in parallel should be prepared to stop rendering the content:

  • In methods that are expected to take many computation cycles, the portlet should check by extended intervals if the flush method of the OutputStream or PrintWriter throws an IOException. If the flush method throws such an exception, the portal has canceled rendering the portlet, and the portlet should terminate its current computation in order to reduce resource usage.

  • This fault tolerant implementation is useful for various situations in which a response can no longer be delivered to the client. For example, this can happen if the network fails, or the client is closed, or the follow-on page request has already been sent or reloaded. Take care to finalize critical backend operations in order to keep back ends in a consistent state. This processing should be done in the action processing phase and not in the render phase. For the Portlet Development Guide refer to http://www.ibm.com/developerworks/websphere/zones/portal/proddoc.html#devguide5.

As the term Parallel Portlet Rendering indicates, only the rendering phase of a portlet is executed in parallel, not the action phase. Therefore, when you write portlets that are rendered in parallel, follow the Model-View-Controller pattern thoroughly.

Parent

Configure portal behavior

Related concepts
Use WSRP services

Related tasks

Use the portal as a WSRP Consumer
Set service configuration properties Portal configuration services

+

Search Tips   |   Advanced Search