Parallel portlet rendering

Configure parallel portlet rendering to optimize the response time of the portal, depending on the configuration. When portlets on a page are rendered sequentially, some portlets can delay output from other portlets to the client browser.

For example, portlets that are waiting for a response from a remote service can cause such delays. Parallel portlet rendering can prevent this delay.

Enabling parallel portlet rendering provides a benefit 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. 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.

We can change the setting for a portlet to parallel rendering in the Manage Portlets portlet. :

1. Select Portal Administration > Portlet Management > Portlets.

2. Select the required portlet and click the Configure (wrench) icon. The portal displays the panel for configuring the portlet.

3. Select check box...
   Enable parallel rendering

Alternatively we can also use the following parameter to enable parallel rendering of a portlet. You set this parameter as a configuration parameter in IBM portlets or as a read-only preference in standard portlets.

parallel = (false)

When true, you indicate that the portlet can be rendered in parallel with other portlets on the page. The default is 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.

Configure portal wide parallel portlet rendering globally for all markups, or individually for the markups of the client devices that display the pages.

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

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

• For parallel rendering of local IBM portlets:

  legacy.useParallelRendering.[markup] = (false)

  Activates the portlet container functionality for parallel portlet rendering for the specified markup. Valid values are true or false . Default is 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, enable the following parameter:

  std.useParallelRendering.[markup] = (false)

  Activates the portlet container functionality for parallel portlet rendering for the specified markup. Valid values are true or false. Default is false. If you omit the markup, the setting applies to all markups for which no specific setting has been defined.

The settings for configuring the parallel portlet rendering parameters are listed and explained in the following list:

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

We can further tune parallel rendering by specifying different values for the following parameters. These parameters apply to both main parallel portlet rendering parameters as previously given.

We can specify the time limits for the parallel rendering process of portlets by the following parameters:

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 stops transferring the portlet content from the parallel pipe to the main response. The default is the value specified by the parallelRenderingTimeOut setting.

parallelRenderingWaitTimeOut = (1)

Specify the 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. Configure the queue handling by setting the following parameter:

parallelRenderingChunkSize = (1024)

Size of the chunks in bytethat are read from the queueDefault is 1024 bytes.

All queues are held in a pool for reuse. We 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 WebSphere Application Server 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 the system resources and the requirements of the 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 we 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, you must selectively disable tracing for com.ibm.wps.pe.PortletRenderTimeLoggingHelper.

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 APIthat 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 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 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 we write portlets that are rendered in parallel, follow the Model-View-Controller pattern thoroughly.

Parent: Configure portal behavior
Related
Use WSRP services
Use the portal as a WSRP Consumer
Set service configuration properties
Portal configuration services