|
|
The process of optimizing your portlets for the best possible performance spans all phases of development. You should continually monitor performance and make appropriate adjustments.
This chapter describes performance optimizations that you can incorporate as you develop portlets.
This chapter contains the following sections:
Customizing performance-related portlet properties can help you improve performance. For example, you can set process-expensive portlets to pre-render or render in a multi-threaded (forkable) environment. If a portlet has been designed as forkable (multi-threaded) you have the option of adjusting that setting when building your portal.
The following portlet properties are performance related:
Portlet Properties includes descriptions of these properties. If you design your portlets to allow portal administrators to adjust cache settings and rendering options, you can modify those properties in the Administration Console.
You can cache the portlet within a session instead of retrieving it each time it recurs during a session (on different pages, for example). Portlets that call web services perform frequent, expensive processing; caching web service portlets greatly enhances performance. Portlet caching is well-suited to caching personalized content; however, it is not well suited to caching static content that is presented identically to all users and that rarely expires.
The ideal use case of the portlet cache is for content that is personalized for each user and expires often. In other situations, it might be more beneficial to use other caching alternatives such as using the wl:cache tag or the portal cache.
For a detailed examination of the Render Cacheable property and a discussion of when you should or should not use it, refer to the dev2dev article Portlet Caching by Gerald Nunn, available at http://dev2dev.bea.com/pub/a/2005/01/portlet_caching.html.
Remote portlets are made possible by Web Services for Remote Portlets (WSRP), a web services standard that allows you to "plug-and-play" visual, user-facing web services with portals or other intermediary web applications. WSRP allows you to consume applications from WSRP-compliant Producers, even those far removed from your enterprise, and surface them in your portal.
While there might be a performance boost related to the use of remote portlets, it is unlikely that you would implement them for this reason. The major performance benefit of remote portlets is that any portal framework controls within the application (portlet) that you are retrieving are rendered by the producer and not by your portal. The expense of calling the control life cycle methods is borne by resources not associated with your portal.
Implementations using remote portlets also have limitations; for example:
If the expense of portal rendering sufficiently offsets the expense of transport and the other limitations described above are inconsequential to your application, using remote portlets can provide some performance boost to your portal.
For more information on implementing remote portlets with WSRP, refer to the Federated Portals Guide.
You can cause process-expensive portlets to render in a multi-threaded (forkable) environment. If a portlet has been designed as forkable (multi-threaded) you have the option of adjusting that setting when building your portal. This allows a portlet to be rendered at the same time as other portlets on the page (that is, in parallel) rather than sequentially. This decreases the overall response time of rendering the portal request (the portal page) back to the user.
In the context of WebLogic Portal, forking (either pre-render or render) refers to page processing that occurs on the server; multiple threads are spawned to process each portlet. In contrast, asynchronous portlet content rendering refers to page processing that occurs on the client browser; multiple threads are spawned, using AJAX or IFRAME technology.
The following sections describe how to implement pre-render and render forking:
| Note: | The same thread safety consideration for asynchronous portlet rendering applies to parallel portlet rendering as well; refer to Thread Safety and Asynchronous Rendering. |
The Fork Pre-Render attribute enables forking (multithreading) in the pre-render life cycle phase. (Refer to "How the Control Tree Affects Performance" in the Portal Development Guide for more information about the control tree life cycle.) Setting the Fork Pre-Render attribute to true indicates that the portlet's pre-render phase should be forked. As with render phase forking, pre-render phase forking is only possible if the portlet's forkable attribute is set to true.
Although using this feature might reduce the response time to the user in most situations, on a heavily loaded system it can actually decrease overall throughput as more threads are being used on the server/JVM for each request—adding to contention for shared resources.
Pre-render forking is supported by these portlet types:
To enable pre-render forking for each portlet type, edit the following portlet properties in the Properties view:
For a description of each property, refer to Table 5-7.
Using forked pre-rendering with asynchronous portlet content rendering is unnecessary and in any case is not recommended, and could result in unexpected behavior.
The Fork Render attribute enables forking (multithreading) in the render life cycle phase. Setting the Fork Render attribute to true indicates that the portlet's render phase should be forked. As with pre-render phase forking, render phase forking is possible only if the portlet's forkable attribute is set to true.
| Note: | Regardless of whether or not you use render forking, the portal does not render until all portlets complete rendering. If you want portlets to render individually, you can use asynchronous portlet rendering, as described in Asynchronous Portlet Content Rendering. |
| Note: | When you use render forking, the HTML that is returned from the server is exactly the same as it would be without forked rendering. The behavior is very different for asynchronous portlet content rendering. for details, refer to |
Render forking is supported by these portlet types:
To enable render forking for each portlet type, edit the following portlet properties in the Properties view:
For a description of each property, refer to Table 5-7.
Using forked rendering with asynchronous portlet content rendering is unnecessary and in any case is not recommended, and could result in unexpected behavior.
Asynchronous portlet rendering allows you to render the content of a portlet independently from the surrounding portal page. This can provide a huge performance boost; for example, when a portal visitor works within a portlet, only that individual portlet needs to be redrawn.
You can use either AJAX technology or IFRAME technology to implement asynchronous rendering. When using asynchronous portlet rendering, a portlet renders in two phases. The normal portal page request process occurs first; during this process, the portlet's non-content areas, such as the title bar, are rendered. Rather than rendering the actual portlet content, a placeholder for the content is rendered. A subsequent request process displays the portlet content.
This section contains the following topics:
A new portlet property asyncContent in the Properties view allows you to specify whether to use asynchronous rendering, and to select which technology to use. An editable dropdown menu provides the selections none, ajax, and iframe. If you want to create a customized implementation of asynchronous rendering, you can do so by editing the .portlet file to set this up; more information about this task will be available in a dev2dev article in the future.
Portlet files that do not contain the asyncContent attribute appear with the initial value none displayed in the Properties view. Any changes to the setting are saved to the .portlet file.
| Note: | Although Browser portlets use an internal implementation that appears similar to that of an asynchronous portlet and both portlet types use IFRAME HTML elements, the actual implementations are quite different. Browser portlets are merely displaying static embedded documents, but asynchronous IFRAME portlets are managed by the framework. |
Keep the following global considerations in mind for any asynchronous rendering implementation:
If navigation is handled by the browser, the behavior of a portlet will vary according to the type of asynchronous rendering technology used, and this inconsistency can be confusing to the end user. For example, with IFRAME technology each portlet interaction is tracked, but this interaction does not update the "view" from the server's perspective; if the user clicks the Back button, the server takes the user to a state preceding the interaction with the portlet.
com.bea.netuix.servlets.controls.portlet.PortletPresentationContext.isAsyncContent()
com.bea.netuix.servlets.controls.portlet.PortletPresentationContext.isContentOnly()
com.bea.netuix.servlets.controls.portlet.backing.PortletBackingContext.isAsyncContent()
com.bea.netuix.servlets.controls.portlet.backing.PortletBackingContext.isContentOnly()
<render:jspContentUrl> or <netui:anchor>. GenericURL.WINDOW_LABEL_PARAM directly to the PostbackURL with the value returned from PortletPresentationContext.getLabel() or PortletBackingContext.getLabel(). If you use asynchronous portlet content rendering, be sure that your code (for example, in backing files) is thread safe. The portal framework handles the major issues outside of a developer's control, such as concurrent access to the request and response; and it manages coordination of issues such as waiting for all async operations to finish and assembling the results in the correct order. But the portlet developer has the responsibility for ensuring that the user code is thread safe.
This consideration also applies to parallel (forked) portlet processing.
Some special considerations associated with IFRAME-based asynchronous rendering include:
<render:context> tag or the AsyncContentContext class as described in Disabling Asynchronous Rendering for a Single Interaction; however, these mechanisms do not work correctly when IFRAME-based asynchronous rendering is used. To avoid this issue, turn off asynchronous rendering or use AJAX-based asynchronous rendering. Some special considerations associated with Asynchronous JavaScript and XML (AJAX)-based asynchronous rendering include:
Table 6-1 summarizes the advantages and disadvantages of IFRAME- and AJAX-based asynchronous rendering. BEA recommends AJAX as a more robust implementation.
The following table compares some of the behavior and features of conventional or forked rendering and asynchronous portlet content rendering.
This section provides more information about life cycle and control tree implications associated with using asynchronous content rendering.
For the initial request for a portal page, backing files attached to the portlet will run in the context of a full portal control tree. However, portlet content—such as page flows, managed beans, JSP pages, and so on—will not run for this initial request.
The values for the above-referenced APIs will be:
PortletBackingContext.isAsyncContent() = true
PortletBackingContext.isContentOnly() = false
For the subsequent content requests, backing files attached to the portlet, and the portlet content itself—such as page flows, managed beans, JSP pages, and so on—will run in the context of a "dummy" control tree.
The values for the above-referenced APIs will be:
PortletBackingContext.isAsyncContent() = true
PortletBackingContext.isContentOnly() = true
PortletPresentationContext.isAsyncContent() = true
PortletPresentationContext.isContentOnly() = true
An important consequence of this model is that when asynchronous content rendering is enabled for portlets, the portlet content will run in isolation from the rest of the portal. Such portlets therefore cannot expect to have direct access to other portal controls such as books, pages, desktops, other portlets, and so on.
Although IPC is not supported when asynchronous content rendering is enabled, WebLogic Portal provides some features that allow these two mechanisms to coexist in your portal environment. In addition, you can disable asynchronous rendering for single requests using the mechanisms described in this section.
This section also applies to HTTP redirects.
| Note: | The techniques described in this section do not currently work with IFRAME portlets. |
For forms containing file upload mechanisms, the WebLogic Portal framework automatically causes page refreshes without the need for any workarounds.
Generally, if a portlet needs to disable asynchronous content rendering for a single interaction (such as a form submission, link click, and so on), you should use the mechanism described in this section.
| Tip: | When you use these mechanisms to disable asynchronous rendering, the portlet's action/rendering will be performed using two requests. The portlet's action is performed in the page request, while the portlet's rendering is performed on a subsequent request. Ensure that your action does not use request attributes to pass information to your JSP page. |
<render:controlContext asyncContentDisabled="true">
Form, anchor, etc. would appear here
(that is, <netui:form action="submit"...)
AsyncContentContext.push(request).setAsyncContentDisabled(true);
// Code that generates a URL would appear here
AsyncContentContext.pop(request)
URL compression interferes with some of the AJAX-specific mechanisms for page refreshes. Because of this, URL compression must also be disabled whenever asynchronous content rendering is disabled to force page refreshes. WebLogic Portal disables URL compression automatically except when file upload forms are used; in this situation, you must explicitly disable it. Use the following examples as a guide:
<render:controlContext urlCompressionDisabled="true">
Form, anchor, etc. would appear here
(that is, <netui:form action="submit"...)
UrlCompressionContext.push(request).setUrlCompressionDisabled(true);
// Code that generates a URL would appear here
UrlCompressionContext.pop(request)
For more information about implementing URL compression, refer to the Portal Development Guide.
|
