Even experienced Java Web developers are often surprised by how big a leap it is to develop a portal. The simple, slick interface that end users see belies the deep power and complexity provided by commercial products like BEA WebLogic Portal. This makes it extremely challenging to diagnose performance issues when portal applications go into production.

This article discusses the performance management challenges of WebLogic Portal and provides a starting point for tuning performance bottlenecks in portal applications. It assumes some familiarity with the terminology and functionality of WebLogic Portal.

A corporate portal allows a company to capitalize more effectively on its digital and human assets while presenting a first-class Web experience to its employees, partners and customers. For this reason, portal applications are becoming business-critical and must deliver reliable performance and scalability. BEA WebLogic Portal is a leading Java EE-based portal server that provides a robust solution for deploying and running portal applications.

WebLogic Portal Architecture
BEA WebLogic Portal combines a unified runtime framework, business services and lifecycle management technologies into a complete Web portal development and delivery platform. It is designed to scale to thousands of end users and support continuous changes.

Figure 1 shows the architecture of the WebLogic Portal hierarchy. When a portal is instantiated, it generates a taxonomy or hierarchy of portal resources known as the WebLogic Portal control tree. The control tree includes desktops, books, pages and portlets. As we'll see, the control tree provides one of the most important keys to understanding performance issues in portal applications.

The basic building block of the portal is the portlet, which is a small portal application, usually depicted as a small box in the 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 syndicated content feeds.

A portlet is developed, deployed, managed and displayed independent of other portlets. Administrators and end users can create personalized portal pages by choosing and arranging portlets, resulting in Web pages with content tailored for individuals, teams, divisions and 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, look up credentials and store persistent data.

Since portlets are servlets, they share similar re-entrance and performance considerations. A single portlet instance (that is, a single instance of the portlet's Java class) is shared among all requesters. As there are a limited number of threads that process portlets and servlets, it is important for each portlet to do its job as quickly as possible so that response time for the whole page is optimized.

Understanding the Control Tree
The WebLogic Portal control tree represents all of the structural elements in the portal and acts as the infrastructure on which a new portal page will be built. A new control tree is created (or drawn from cache if it exists already) during control tree processing when the portal is instantiated. One of the most significant impediments to portal performance lies with the number of controls on a portal. The more portal controls (pages, portlets, buttons, etc.) you have, the larger your control tree - and the longer it will take to render all the components.

Figure 2 shows a control tree generated for a typical portal. From the desktop and shell is created a main book and six sub-books, which in turn contain two pages each. Each page contains two portlets. So, in total, this portal has a minimum of 42 controls.

Once the control tree is built and all the instance variables are set on the controls, the tree must run through the lifecycle for each control before the portal can be fully rendered. The lifecycle methods are called in order. That is, all the init() methods for each control are called, followed by the loadState() method for each control, and so on in the order determined by the position of each control in the portal's taxonomy.

Running each control through its lifecycle requires some overhead processing time, which, when you consider that a portal might have thousands of controls, can grow exponentially. Thus, you can see that the larger the portal's control tree the greater the performance hit.

Monitoring Performance in WebLogic Portal
Portal performance is generally measured by the amount of time required to actually render that portal and all of its constituent parts when a visitor clicks an object that sends a request to the portal servlet.

The first challenge is simply in monitoring and measuring overall performance of the portal. Built-in management functionality really does not do a thorough enough job of this for the entire system, specifically the individual portal components (including portlets and other code run by the WebLogic Portal container), connections to any and all databases, transaction servers, mainframe systems and other back-end systems.

Whatever tool or tools you use needs to be able to:

• Monitor the complex, dynamic interactions taking place across the entire workflow and within individual processes,
• Present the resulting data in a clear, simple display that highlights problems (and where they occur in the portal workflow), and allow the administrator to quickly drill down - to individual portlets and transactions if need be - to the source of the problem, and
• Summarize overall performance as well as performance in the key portal workflow areas: portal servlet, control tree processing, JSP backing files, Java page flows, portlets, connections to back-end systems and portal services.

Portal Request Response Time
Since portals are personalized Web applications, it is important to measure portal performance as an end user would experience it. By monitoring live transaction response times, the portal administrator can take proactive measures to address a problem before it impacts users and the business.

Control Tree Processing
Remember that the control tree represents all of the structural elements in the portal and acts as the infrastructure on which a new portal page will be built. Almost all of the elements in the user-interface design correspond to controls in this tree. Get visibility into the complex processes taking place within the control tree as well as its interactions with the "View" and "Control" elements of the portal. Figure 3 shows how a performance tuning tool might highlight a control tree performance issue.

Portlets
Applications, JSP-based portlets, Web Services or other available J2EE resources can all be exposed as portlets. If a performance slowdown occurs, application support personnel need the ability to determine quickly which individual portlets may be responsible. Within the portlet lifecycle, handling post back data and pre-rendering are processes that are especially important to monitor for performance.

Portal Framework Services
JSP backing files work in conjunction with JSPs, allowing separation of the presentation logic from the business logic. Always run before the JSPs, the backing files typically contain a great deal of custom rendering code (and additionally, some developers make callouts to back-end systems to fetch additional data to render). Poor performance is usually an indication of misbehaving custom rendering code.

In Java page flows, the page flow itself is entirely defined by the developer; slowness can usually be diagnosed by the author, and isn't usually caused by trouble with any back-end system. It may also be helpful to correlate the J2EE standard page flows to the portal control tree processing architecture to determine which page flow is tied to which desktop.

WebLogic Portal Services
The Entitlement system provides role-based authorization to individual portal resources. Entitlements are used heavily by all aspects of the portal, so any slowness impacts the whole system. Often, delayed responses and stalled threads are caused by trouble in the back-end systems supporting Entitlements, such as LDAP. Additionally, entitling too many objects at a fine level of granularity can overload the Entitlements system.

The Personalization service, implemented through advislets, modifies the information displayed in the portal preferences. Advislets can use many mechanisms - an internal rules engine, explicit personalization or even events. Overuse of the Personalization system overall is a common cause of performance problems.

The User Profile repository contains additional user information such as contact information. Often, delayed responses and stalled threads are caused by trouble in the back-end systems, such as a database used for supporting user profiles.

The Content Management API interfaces with a number of commercially available content management systems, such as Documentum. When stalled threads occur here, one of the first things to check is whether the back-end content system is performing normally.

Conclusion
We hope this has been a useful introduction to the performance challenges posed by WebLogic Portal applications. As enterprise portal offerings grow in popularity and complexity, so does the challenge of managing their performance and availability. With the proper tools and process, portal-based applications can be depended upon to consistently deliver their promised business value.