Parallel portlet rendering

 

+

Search Tips   |   Advanced Search

 

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. Parallel portlet rendering can prevent this delay.

Default for portal and individual portlets is not to be rendered in parallel.

The settings for both the portal and individual portlets need to be set to enable parallel portlet rendering. 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.

You 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 desired portlet and click on the Configure (wrench) icon. The portal displays the panel for configuring the portlet.

3. Mark the Enable parallel rendering checkbox to enable parallel rendering for the portlet.

Alternatively 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 you set this parameter to 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.

You can 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. Doing so would trigger additional rendering processes for those portlets which are not displayed and thereby decrease performance.

Portal wide settings for parallel portlet rendering are set in the PortletContainerService.

For parallel rendering of local IBM portlets...

legacy.useParallelRendering[.markup] = (false)

Activates the portlet container functionality for parallel portlet rendering for the specified markup [false = default, true]. 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 integrated in a WSRP Consumer portal...

std.useParallelRendering[.markup] = (false)

Activates the portlet container functionality for parallel portlet rendering for the specified markup [false = default, true]. If you omit the markup the setting applies to all markups for which no specific setting has been defined.

Parallel portlet rendering...

false

Parallel rendering is disabled. This is the 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

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

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

parallelRenderingTimeOut = (2000)

Specify the timeout in milliseconds after which the render process of a portlet is aborted. The default is 2000 milliseconds (= 2 seconds).

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. You can configure the queue handling by setting the following parameter:

parallelRenderingChunkSize = (1024)

Specifies the 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 your system resources and the requirements of your 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.

 

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, 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 abort 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 topic

Configure portal behavior

 

Related tasks

Set service configuration properties

 

Related reference

Portal configuration services

---