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 more information about designing portals.
This chapter covers a few configuration settings and key areas that can be optimized according to your needs and includes the following sections:
Portal web applications use a control tree to cache and access different functionality. For example, portals use controls to access desktops, books, pages, portlets, and menus. When you create 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. However, the use of multilevel menus negates much of the performance benefit that control tree optimizations provide. This is due to the menu traversing the control tree in order to build up the multilevel menu.
Your portal application uses 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. Four configuration files that are key to portal performance include:
netuix.config.xml (portal framework)
web.xml (web application settings)
weblogic.xml (server settings)
p13n-cache-config.xml (portal cache settings)
For most settings you can adjust them using either the WebLogic Server Console or the WebLogic Portal Administration Console. 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 under WEB-INF.
Table 4-1 lists key performance tuning elements within the netui-config.xml file.
Table 4-1 netui-config.xml
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 but keep in mind that there will be an impact on the performance of the system with the use of this feature.
<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>
A switch to indicate that a portal is setup to use entitlement policies (users able to view 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. Using entitlements will result in additional overhead for WebLogic Portal.
<localization>
A switch to indicate that a portal supports multiple locales. This should be disabled if a portal supports only one locale.
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>
This setting allows you to determine when to start tracking anonymous users and is ignored unless you are tracking anonymous users. The longer you wait during a session to start tracking anonymous users, the less performance overhead there will be on the server.
<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. For example, the tutorial portal sends requests for images, JavaScript, and CSS files. Ignoring these requests for PortalServletFilter processing increases performance and guarantees that tracking anonymous users will behave as expected.
The following parameters can be adjusted for performance. 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 – 1 to disable page checking and recompiling.
<servletReloadCheckSecs>
Sets the interval, in seconds, at which WebLogic Server checks to see if servlet files have changed and need recompiling. Dependencies are also checked and recursively reloaded if changed.
If set to 0, servlets are checked on every request. This default is preset for a development environment. If set to – 1, servlet checking and recompiling is disabled.
In a production environment where changes to a servlet are rare, change the value of servletReloadCheckSecs to – 1 to disable servlet 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.
Note:
In a clustered production environment, it is important that you configure the PersistentStoreType property in weblogic.xml to enable session replication to take place across the cluster. To do this, set the element to the replicated_if_clustered value. Without this setting, you will not have failover of a user’s state information if a server in the cluster is stopped. By default if persistent-store-type is not set, it defaults to disabling persistent session storage. Also note that there will be increased memory utilization and additional overhead on the system with this feature enabled.
<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.
<debug>
Turn off debugging by setting debug property to false.
<precompile>
Precompile the JSPs in the web application to reduce the time needed to display pages on their first invocation by setting precompile to true.
<precompile-continue>
Also set <precompile-continue> to true, because if any JSPs do not compile, deployment of the web application stops.
Note:
Alternatively, you can use weblogic.appc to precompile JSPs. See the WebLogic Server documentation for more information.
WebLogic Portal Cache Settings
You can modify the p13n-cache-config.xml file via the WebLogic Portal Administration Console. For more information on how to modify the cache and a comprehensive list of WebLogic Portal Caches see the Weblogic Portal Cache Reference chapter in the Cache Reference Guide.
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
