Performance Tuning Guide

Tuning Your Portal Web Application

One of the key things you can do to ensure good performance for your web application is to design appropriately, see Designing Portals for Optimal Performance for hints and tips that will increase performance.

This chapter covers a few configuration settings and key areas that can be optimized according to your needs and includes the following sections:

Optimizing Your Portal Control Tree

Portal web applications use a control tree to cache and access different functionality. For example, portals use controls to access desktops, windows, books, pages, portlets, and menus. With WebLogic Portal 8.1 SP4 and higher, users creating complex portals that require a large number of controls, tree optimization is the easiest way to ensure optimal portal performance. Controls that are not active in the current portal instance are not built, saving considerable time and overhead.

For more information about how control trees work see http://download.oracle.com/docs/cd/E13218_01/wlp/docs81/whitepapers/netix/body.html#1056016

For more information about when to optimize your control tree, see Designing Portals for Optimal Performance.

Modifying Your Portal Web Application Parameters

Your portal application uses a configuration files to store application settings. Some default settings may not be applicable to your particular portal application.

Each portal application uses unique configuration files to customize parameters that can affect performance. Three configuration files that are key to portal performance include:

netuix.config.xml (portal framework)
web.xml (web application settings)
weblogic.xml (server settings)

For most settings, you can adjust them using either the WebLogic Server Console or the Administration Portal. However, many of the settings discussed in this section must be manually entered in the configuration file.

Modifying Portal Framework Settings

The netuix-config.xml file resides in the portal web application directory. For example, if you are using the sample portal web application, the corresponding netuix-config.xml file is located at:

//weblogic81/samples/portal/portalApp/sampleportal/WEB-INF/netuix-config.xml

After making any changes, you must redeploy your web application for the changes to take effect. For more information about modifying web descriptor files, see Preparing The EAR File for Deployment in the Production Operations User Guide.

For more information about Portal Framework performance issues and the netuix-config.xml file see http://download.oracle.com/docs/cd/E13218_01/wlp/docs81/whitepapers/netix/appendix.html#1052773.

Table 4-1 lists key performance tuning elements within the netui-config.xml fle.

Table 4-1

Element	Usage Notes
`<customization>`	A switch to indicate if a portal is customizable or not. If a portal is served from a .portal file (rather than from a database) and users are not allowed to customize it then customization can be disabled by setting `enable` element's value to `false`. If a portal supports customizations then customization should be enabled.
`<pageflow>`	A switch to enable or disable page flows usage in a portal. Disable it if a portal is not using any page flows.
`<validation>`	A switch for validating portal related files such as `.pinc`, `.portlet`, and `.portal` files. Disable validation when running portal server in production.
`<entitlements>`	The `<entitlements>` element is a switch to indicate that a portal is setup to use entitlement policies (users to portal resources such as desktop, books, pages, portlets, and so on). Disable entitlements if a portal is not using any security policies. If a portal is using security policies, enable it and set the value for `<control-resource-cache-size>` attribute using number of desktops + number of books + number of pages + number of portlets + number of buttons (max, min, help, edit) used in a portal. The default value could be used if memory is a concern. For more information, see Tuning for Entitlements on page 3-5.
`<localization>`	A switch to indicate that a portal supports multiple locales. This could be disabled if a portal supports only one locale.

netui-config.xml

Modifying Web Application Settings

The web.xml file configures your web application. After making any changes, you must redeploy your web application for the changes to take effect. For more information about modifying web descriptor files, see Preparing The EAR File for Deployment in the Production Operations User Guide.

The web.xml file is located in the WEB-INF subdirectory of your portal web application directory. For example, if you are using the sample portal web application, the corresponding web.xml file is located at:

<BEA home>/weblogic81/samples/portal/portalApp/sampleportal/WEB-INF/web.xml.

Table 4-2 lists key elements of the web.xml file.

Table 4-2 web.xml

Parameter	Usage Notes
`<createAnonymousProfile>`	Set this to false if your portal does not store or use user profile information.
`<enableTrackedAnonymous>`	Set this to false unless you are tracking anonymous users. When this is set to false, only users who login to the portal are tracked.
`<fireSessionLoginEvent>`	Set this to false unless using campaigns or behavior tracking. If this is set to true, session login events are generated
`<trackedAnonymousVisitDuration>`	Set to determine the when during a session you start tracking anonymous users. Ignored unless you are tracking anonymous users. This setting allows you to determine when to start tracking anonymous users. The longer you wait during a session to start tracking anonymous users, the greater the performance.
`<skipRequestPattern>`	Set to determine which request patterns to skip. Each page displayed in a web application may have many separate requests, several of which are irrelevant to TAU. For example, the tutorial portal sends requests for images, java script, and CSS files. Ignoring these requests for PortalServletFilter processing increases performance and guarantees that tracking anonymous users will behave as expected.

Modifying WebLogic Server Settings

You can modify the weblogic.xml file via the WebLogic Server Console. For more information on how to modify these settings see Viewing and Updating Run-Time Deployment Descriptors in the WebLogic Server Console online help.

The following parameters can be adjusted for performance. For more information about the weblogic.xml file, see http://download.oracle.com/docs/cd/E13222_01/wls/docs81/webapp/weblogic_xml.html#1037041 for a complete list of the elements configured in the weblogic.xml file.

Table 4-3 lists key performance tuning elements in the weblogic.xml file.

Table 4-3 weblogic.xml

Parameter	Usage Notes
`<jspPageCheckSeconds>`	Sets the interval, in seconds, at which WebLogic Server checks to see if JSP files have changed and need recompiling. Dependencies are also checked and recursively reloaded if changed. If set to 0, pages are checked on every request. This default is preset for a development environment. If set to -1, page checking and recompiling is disabled. In a production environment where changes to a JSP are rare, change the value of `pageCheckSeconds` to 60 or greater, according to your tuning requirements, or to -1 to disable page checking and recompiling.
`<PersistentStoreType>`	Must be edited manually. Sets the persistent store method to one of the following options: `memory`—Disables persistent session storage. `file`—Uses file-based persistence. `jdbc`—Uses a database to store persistent sessions. `replicated`—Same as memory, but session data is replicated across the clustered servers. `cookie`—All session data is stored in a cookie in the user's browser. `replicated_if_clustered`—If the web application is deployed on a clustered server, the in-effect PersistentStoreType will be replicated. Otherwise, memory is the default.
`<Timeout Secs>`	Sets the time, in seconds, that WebLogic Server waits before timing out a session, where x is the number of seconds between a session's activity. Minimum value is 1, default is 3600, and maximum value is integer `MAX_VALUE`. On busy sites, you can tune your application by adjusting the timeout of sessions. While you want to give a browser client every opportunity to finish a session, you do not want to tie up the server needlessly if the user has left the site or otherwise abandoned the session. This attribute can be overridden by the session-timeout element (defined in minutes) in `web.xml`.

Tuning Guidelines for WSRP

For more information about performance guidelines for Web Services Remote Portlets, see Best Practices for Implementing WSRP.

Enabling Caches for WSRP

If you are using WSRP portlets, adjust your caches accordingly. For specific information about WSRP caches, see WSRP Caches on page B-5.

Tuning the Server for WSRP

When using WSRP portlets from a server that is running on a Unix machine, be sure to modify the parameters in the /etc/system file to match the minimum requirements, as noted in the WebLogic Server Performance and Tuning Guide.

It is also recommended that you tune the Server Execute Queue using the instructions mentioned Tuning the Default Execute Threads, in the WebLogic Server Performance and Tuning Guide.

Other recommendations include:

Set the Server Execute Queue to a maximum of 25 threads. Additional threads do not provide higher performance.
Match the number of JDBC connection pools to the number of threads set in the Server Execute Queue, see Configuring JDBC Connection Pools in the "Creating WebLogic Configurations Using the Configuration Wizard" guide.
Match the number of threads set in the portalRenderQueue to the threads set for the Server Execute Queue.

Caching Portlet Categories

Portlet category information is automatically cached, which enhances performance. If for any reason you do not want to cache portlet categories, you can turn off this cache by setting the following system property:

-enable.portlet.category.caches=false