WebLogic Portal Performance Management

Even experienced Java Web developers will be amazed at the huge leap in the development portal. Behind the simple, beautiful interface that end users see is the power and complexity of commercial products such as the BEA WebLogic Portal. Diagnosing performance problems can be especially difficult when the portal application is in the production phase.

This article assumes that you are already familiar with the features and terminology of the WebLogic portal.

A company's portal enables companies to leverage their technical and human assets more efficiently while providing a best-in-class Web experience for their employees, partners, and customers. For this reason, portal applications are now critical to the business and provide reliable performance and scalability. The BEA WebLogic Portal is a leading Java EE Gateway server that provides robust solutions for deploying and running portal applications.

WebLogic Portal Architecture

The BEA WebLogic Portal integrates a unified runtime framework, business services, and lifecycle management technologies into a complete web portal development and delivery platform. It can be extended for thousands of end users and supports continuous changes.

Figure 1 shows the WebLogic Portal architecture. When the portal is instantiated, it generates a classification or hierarchy of portal resources, the so-called WebLogic Portal control tree. The control tree includes desktop, book, and Portlets. As you can see, the control tree is critical for understanding performance issues in Portal applications.

Figure 1. Hierarchical architecture of WebLogic Portal

The basic building block for portals is that Portlet,portlet is a small portal application that is often described as a small box within a Web page. They are reusable components that provide access to applications, web-based content, and other resources, and can access and display Web pages, Web services, applications, and chain content feeds.

Portlets are developed, deployed, managed, and displayed independently of each other. Administrators and end users can create personalized portal pages by selecting and arranging portlets, so that Web pages can be tailored to individuals, teams, departments, or organizations. Portlets rely on the portal infrastructure to access user profile information, participate in window and action events, communicate with other portlets, access remote content, find vouchers, and store persistent data.

Because portlets are also servlet, they share similar reentrant and performance concerns. A single portlet instance (that is, a single instance of a Portlet's Java Class) is shared by all requesters. Because the number of threads working on Portlets and Servlet is limited, it is important that each portlet completes its job as quickly as possible so that the response time for the entire page can be optimized.

Understanding the control tree

The WebLogic portal control tree represents all the architectural elements within the portal and serves as the infrastructure required to build a new portal page. When the portal is instantiated, the new control tree is created (or purged from the cache, if the control tree already exists) during the control tree processing. One of the great obstacles to portal performance is the number of controls within the portal. The more Portal controls (pages, portlets, buttons, and so on), the larger the control tree, and the longer it takes to render all the components.

Figure 2 shows a tree of controls generated for a typical portal. The desktop and the shell create a main book and 6 children, each containing 2 pages. Each page contains 2 portlets. As a result, the entire portal contains at least 42 controls.

Figure 2. A typical control tree for a portal instance

Once the control tree is built and the instance variable is set successfully, the tree must run for each control throughout its lifecycle before the portal is fully rendered. Life cycle methods are called sequentially. That is, the init () method for each control is invoked, followed by the LoadState () method for each control, and so on, and the order of the calls is determined by the position of each control in the portal classification diagram.

Running each control in the lifecycle requires some overhead processing time, and if the portal has thousands of controls, it is likely to grow exponentially at that time. As a result, the larger the portal control tree, the more serious the impact on performance.