Insights into WebLogic Portal Performance Management

®

written byRini Gahir

Senior Product Marketing ManagerQuest Software, Inc.

White Paper

Insights intoWebLogic Portal

Performance Management

© Copyright Quest® Software, Inc. 2006. All rights reserved.

The information in this publication is furnished for information use only, does not constitute a commitment from Quest Software Inc. of any features or functions discussed and is subject to change without notice. Quest Software, Inc. assumes no responsibility or liability for any errors or inaccuracies that may appear in this publication.

Last revised: April 2006

Insights into WebLogic Portal Performance Management - Rini Gahir, Quest Software, Inc. 3

TABLE OF CONTENTS

THE PORTAL VISION .................................................................................................................. 4 BEA WEBLOGIC PORTAL OVERVIEW ........................................................................................... 5 THE PORTAL PERFORMANCE MANAGEMENT CHALLENGE ............................................................. 6

PORTLETS ................................................................................................................................... 7 PORTLET PERFORMANCE ............................................................................................................ 7 WEBLOGIC PORTAL CONTROL TREE............................................................................................ 8

WebLogic Portal Performance Management....................................................................... 10 Key Areas to Monitor ........................................................................................................... 10

CONCLUSION ............................................................................................................................ 14 ABOUT QUEST SOFTWARE, INC. ........................................................................................... 15

CONTACTING QUEST SOFTWARE ............................................................................................... 15 TRADEMARKS............................................................................................................................ 15


THE PORTAL VISION

Portals serve as simple, unified access points for Web applications, but also do much more: they provide valuable functions like security, search, collaboration and workflow. A portal delivers integrated content and applications, plus a unified, collaborative workplace to a variety of client devices over the Web.

Companies can reap tangible business and technical benefits from implementing portal applications, such as:

• Revenue benefits from tighter relationships with customers or partners, work force productivity, innovation and reduced cycle times

• Operational cost reduction from increased operational efficiency, better information flow and knowledge and consistent infrastructure

• Increased employee productivity and improved decision making from access to more relevant information, and a single access point to applications and collaboration tools

• Better security and single sign-on, resulting in fewer passwords to administer and a better user experience

• Reduced training costs, resulting from common presentation and a consistent user interface

• Unification of applications, giving them a longer useful life, with new ways of accessing them through desktop and pervasive devices

A corporate portal allows an e-business to quickly capitalize on their digital and human assets while presenting a first-class Web experience to their employees, partners and customers. For this reason, portal applications are becoming business-critical and must live up to the demands of reliable performance and scalability. BEA’s WebLogic Portal server is a leading portal server that provides a robust solution for deploying and running portal applications. This paper will discuss some intricacies involved with managing and optimizing the performance of WebLogic Portal applications.


BEA WebLogic Portal Overview

Commercial J2EE portal servers, such as BEA WebLogic Portal, simplify information access, improve IT productivity and provide a low–cost path for customization of the presentation layer. As a result, they enable enterprises to deliver new, customized business services rapidly, at a lower cost and with far more change tolerance than any prior technology.

BEA WebLogic Portal combines a unified runtime framework, business services and lifecycle management technologies into a seamless Web portal development and delivery platform that can scale to thousands of end users and support the continuous change required by both new business requirements and existing content.

WebLogic Portal Platform

Figure 1: An illustration of the WebLogic Portal platform.

This enables companies to deliver Web-based applications in months instead of years, with smaller IT teams, a lower total cost of ownership and simplified production. But, as portal applications move from development and testing into staging and deployment, production teams within large corporations find they need advanced technology in order to assure optimal performance and availability for these customized, Web-based business services.


The Portal Performance Management Challenge

Performance is always an issue in the acceptance of an enterprise-level software solution and WebLogic Portal is not immune to these issues. However, many performance problems are not the result of flaws in the product, rather the result of poor decisions made during the application development design phase. Proper planning allows you to take advantage of the inherent strengths of WebLogic Portal to ensure optimal performance for your portals.

Portal performance is usually 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. 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 longer it will take to render all the components.

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 and is discussed later in this paper.

Figure 2: An illustration of the hierarchy created by WebLogic Portal. This is also known as the WebLogic Portal control tree.

For a detailed description of WebLogic Portal, visit BEA's WebLogic Portal e-docs site at: http://e-docs.bea.com/wlp/docs81/.

In the following sections we will discuss the various portal components and their impact on performance.

http://e-docs.bea.com/wlp/docs81/


PORTLETS

Portlets are the heart of a portal. The term “portlet” refers to a small portal application, usually depicted as a small box in the Web page. Portlets are reusable components that provide access to applications, Web-based content and other resources. Web pages, Web services, applications and syndicated content feeds can be accessed through portlets. Companies can create their own portlets or select from a catalog of portlets created by BEA and by BEA business partners.

Any particular portlet is developed, deployed, managed and displayed independent of other portlets. In addition, 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, lookup credentials and store persistent data.

Portlet Performance

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

Portlet output can also be cached. The caching policies are configured in the portlet deployment descriptor, including an expiration time and whether or not the portlet markup can be shared among users or is user-specific.


WebLogic Portal Control Tree

As discussed above, 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. During control tree processing, a new control tree is created (or drawn from cache if it already exists). 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.

p1 p2

P1

p3 p4

P2

B1

p1 p2

P3

p3 p4

P4

B2

p1 p2

P5

p3 p4

P6

B3

p1 p2

P7

p3 p4

P8

B4

p1 p2

P9

p3 p4

P10

B5

p1 p2

P11

p3 p4

P12

B6

Main�Book

Shell

Desktop

Bn

Pn

pn

Sub-�Books

Pages

Portlets

Figure 3: This illustration depicts a single portal with a main book containing six sub-books, which in-turn contain two pages each and each page contains two portlets. In total, this portal has a minimum of 42 portal 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 an order determined by the position of each control in the portal’s taxonomy. For example, the control tree illustrated in Figure 4 depicts the taxonomy a simple portal comprised of a book (B1) containing two pages (P1 and P2), which each contain two portlets (p1-p4; note that p2 also contains its own subordinate book, page and portlet hierarchy).

B1

B2

P1

p6p5

p4p3p2p1

P3

P2Init()

loadState()

raiseChangeEvents()

handlePostBackData()

If _nfpb=true

If handlePostBack-Data()=true

If handlePostBack-Data()=false

preRender()

saveState()

Dispose()

Portlet LifecycleMethods

Figure 4: This illustration depicts the control tree and the lifecycle of each control.

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 larger the portal's control tree the greater the performance hit.

Refer the BEA’s documentation on Optimizing the Portal Control Tree for best performance.


WebLogic Portal Performance Management

To help administrators maintain the performance and availability of enterprise portals, an effective management tool should monitor not only individual portal components and workflow processes, but also the environment surrounding the portal, including connections to databases, transaction servers, mainframe systems and other back-end systems. Portal administrators require a tool that:

• Monitors the complex, dynamic interactions taking place across the entire workflow and within individual processes.

• Presents the resulting data in a clear, simple display that highlights problems (and where they occur in the portal workflow), and allows the administrator to drill quickly down—to individual portlets and transactions, if need be—to the source of the problem.

• Summarizes 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.

Key Areas to Monitor

In the workflow described above, several areas are potential sites for problems that can affect portal performance and availability. Quest’s Performance Management Suite for Java and Portals addresses WebLogic Portal monitoring in these key areas:

• 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 the business.

Figure 5: Quest provides constant monitoring of end-user requests that will alert the administrator when a problem is encountered.


Figure 6: Quest can isolate the server tier where the problem may exist. In this example, the response time problem seems to exist within the Portal Server.

• Control Tree Processing - As described above, 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. It is necessary to have 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 7: The Quest solution displays the WebLogic Portal Control Tree and highlights the most expensive performing components. In the above example, the My Task List portlet seems to be the most expensive component.

• Portlets - Portlets are one of the basic elements of any portal solution. 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.


Figure 8: The Quest solution can highlight the actual Java methods that are invoked in processing the individual portal component.

• Portal Framework Services: • JSP Backing Files—backing files work in conjunction with JSPs. The JSPs allow the

developer to code the presentation logic, while the backing files allow the developer to code simple business logic. Backing files are always run before the JSPs. Typically, a great deal of custom rendering code is here (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.

• Java Page Flows—the page flow itself is entirely defined by the developer. Slowness in the Java Page Flow 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 • Entitlements—the Entitlement system provides role-based authorization to

individual portal resources. Naturally, there are a lot of API calls involving roles. 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.

• Personalization—this 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.


• User Profiles—this is the repository for additional user information—anything from contact information to favorite ice cream flavor. Often, delayed responses and stalled threads are caused by trouble in the back-end systems, such as a database used for supporting user profiles.

• Content Management—this is a common API that can interface with a number of commercially available content management systems (such as Documentum). The Content Management API provides a uniform interface for back–end communication with these content management systems. When stalled threads occur here, one of the first things to check is whether the back–end content system is performing normally.

Figure 9: Quest provides comprehensive monitoring across the portal application environment including: portal services, the portal framework, portal control tree and portlet performance.


CONCLUSION

A complete portal solution should provide users with convenient access to everything they need to get their tasks done anytime, anywhere, in a secure and timely manner. However, as enterprise portal offerings grow in popularity and complexity, so does the challenge of managing portal performance and availability. With the proper tools and process, portal-based applications can be depended upon to consistently deliver their promised business value. Quest’s Performance Management Suite for Java and Portals can help companies meet the challenge of managing next-generation portals.


ABOUT QUEST SOFTWARE, INC.

Quest Software, Inc. delivers innovative products that help organizations get more performance and productivity from their applications, databases and Windows infrastructure. Through a deep expertise in IT operations and a continued focus on what works best, Quest helps more than 18,000 customers worldwide meet higher expectations for enterprise IT. Quest Software can be found in offices around the globe and at www.quest.com.

Contacting Quest Software

Mail: Quest Software, Inc. World Headquarters 5 Polaris Way Aliso Viejo, CA 92656 USA Web site www.quest.comEmail: [email protected]: 1.800.306.9329 (Inside U.S.) 1.949.754.8000 (Outside U.S.)

Please refer to our Web site for regional and international office information. For more information on Quest Software solutions, visit www.quest.com.

Trademarks

All trademarks and registered trademarks used in this guide are property of their respective owners.

http://www.quest.com/


mailto:[email protected]


Technology

Insights into WebLogic Portal Performance Management