Performance Tuning Guide

Tuning Your Portal Application

Key aspects of portal performance are managed at the portal application level. These include:

Managing Caches

WebLogic Portal provides a single framework for configuring, accessing, monitoring, and maintaining caches. If configured properly, the caches can vastly reduce the time needed to retrieve frequently used data. Keep in mind that caches are read-only and cluster-aware.

Many WebLogic Portal services use preconfigured caches that you can tune to meet your performance needs. Some services use internally configured caches that you cannot configure or access. If you extend or create additional services, you can use the cache framework to define and use your own set of caches.

WebLogic Portal Cache Settings lists caches that might be used by your portal application. Use the list to assist you in your tuning. Keep in mind the memory that is available to your system. When modifying the maximum cache sizes, also monitor the system memory to determine the effects.

Using the Portal Administration Tool to Configure Cache Settings

You can use the Service Administration tools within the Portal Administration tool to configure statically-defined caches. For a list of configurable caches, see WebLogic Portal Cache Settings.

When you configure a cache, you modify its parameters to change its behavior or capability. Each cache has a Max Size setting and a Time To Live setting. For example, you can set up a cache to hold only the last 10,000 entries, and set the time they can remain in the cache. You can also flush the cache so that all new requests for information come directly from the database.

For instructions on how to configure cache settings, see Configuring Cache Settings.

Caching with JSP Tags

Some WebLogic Portal JSP tags support caching results at various scopes such as session or page. This allows for more control over the caching of individual content queries. Although this can be seen as an advantage, remember that when you control caches with coding, any cache change will require more maintenance, depending on the size (amount of code) of your application.

The following content management-related JSP tags include cache-related attributes:

<cm:search>
<cm:getNode>
<pz:contentSelector>
<pz:contentQuery>

For more information about these JSP tags and their attributes, see Portal JSP Tags in the WebLogic Workshop online help.

Disabling Unused Services

When you create a new portal application, WebLogic Portal enables most services such as commerce services, event listening and campaigns. If your portal application does not require these services, you can improve performance by turning them off.

You can disable services by using the Administration Portal via the Service Administration page; see Adding/Removing Configurable Items in the Administration Portal online help.

The following services should be disabled if your application does not use features that are dependent on them:

Event services (used for behavior tracking)
Behavior Tracking services

Tuning for Campaigns

Campaigns are powerful tools for personalization, letting you target users with specific web content, e-mails, and discounts based on fine-grained rules. The following tips allow you to tune your campaign settings to ensure better performance.

Referencing Events

Always make scenario rules dependent on a particular event. This allows optimizations based on the event types referenced in the scenario rules.

Avoiding Firing Extraneous Events

Whenever possible, avoid firing any extraneous events. The campaign services must listen to all events. Use events to signify important occurrences on the site.

Using Goal Checking for Campaigns

If you are using campaigns that take advantage of goal checking, set the goal checking appropriately. Goal checking is used to determine if a campaign's goals are met. When your developers create campaigns, they can set them to end on a specific date or use a set of goals (for example, number of views or clicks). You should set it according to the duration of your campaign. If a campaign's goal check mechanism is set too low, it will affect portal performance. The default is 300000 milliseconds (five minutes).

You can adjust the goal check time for campaigns using the Administration Portal.

For more information about how to adjust this setting, see Configuring a Campaign Service in the Administration Portal online help.

Using Ads During Campaigns

The Campaign service uses display counts to determine whether a campaign has met its end goals. Each time an ad placeholder finds an ad to display as a result of a scenario action, the Campaign service updates the display count.

By default, the Campaign service does not update the display count in the database until an ad placeholder has found 10 ads to display as a result of one or more scenario actions. For performance tuning you can change this default to decrease the database traffic needed to support a campaign.

For sites with high traffic, increase this number to a range of 50 to 100.

To configure the Ad Service cache, use the Administration Portal to perform the following steps:

From the Administration Portal, choose Service Administration.

In the Application Configuration Settings Resource tree, select Ad Service Group.

Adjust the Display Flush Size to a number appropriate for your portal needs. The default is 10.

Click Update.

Tuning for Entitlements

If your portal uses entitlements, you will need to configure your application to recognize them. You can do this by editing the netuix-config.xml file.

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

Edit the netuix-config.xml file to include the following text:

<entitlements control-resource-cache-size="200">

    <enable>true</enable>

</entitlements>

If your portal uses a large number of entitlements (more than 5000) it can be beneficial to customize the cache settings for Weblogic Entitlements Engine.

Create an entitlement.properties file that contains the following:

weblogic.entitlement.engine.cache.max_role_count=2000
weblogic.entitlement.engine.cache.max_resource_count=5000
weblogic.entitlement.engine.cache.max_predicate_count=200
These values are the default for each property. You can change these if necessary.

Edit your system classpath to include this new file. If the properties file resides in the web application's WEB-INF/classes directory it is automatically included in the classpath. If for any reason you need to keep this file elsewhere, see http://download.oracle.com/docs/cd/E13222_01/wls/docs81/admin_ref/weblogicServer.html#SettingClasspath for more information about editing your system classpath.

After completing the changes, you need to redeploy your portal application.

Using Role Caching When Using Entitlements

Starting with WebLogic Portal 8.1 SP4, role values are cached automatically. However, if you decide to define roles with expressions whose evaluation changes within the course of processing a request, you may need to disable this setting.

To disable role caching, you need to edit the web.xml file for the respective application.

Note: 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.

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

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

Open the web.xml file in a text editor.

Add the following lines

<env-entry>

<env-entry-name>p13n.entitlements.disableRoleCache</env-entry-name>
<env-entry-value>Y</env-entry-value>
<env-entry-type>java.lang.String</env-entry-type>

</env-entry>

Save the new web.xml file.

Redeploy your web application.

Tuning for Content Management

When you use a BEA repository for your content management, you can tune the cache settings according to the needs of your portal applications.

Repository cache settings are accessed when you edit a repository.

You can adjust cache settings for nodes (content folders) or binaries (a content item) according to how often your content is accessed and how much content you want to remain in the cache. Keep in mind that your server must have enough memory to handle the cache settings you assign.

Table 3-1 Node Cache

Cache Setting	Usage Notes
Maximum Entries	Determines the maximum number of entries (folders) that can be cached.
Time To Live	Determines how long the entries will be cached.
Enable	Enables the cache. Mark this checkbox to enable this cache. To disable this cache, unmark the checkbox.

Table 3-2 Binary Cache

Cache Setting	Usage Notes
Maximum Entries	Determines the maximum number of entries (content items) that can be cached.
Time To Live	Determines how long the entries will be cached.
Cache Size/Item	Sets the maximum size of a single entry (content item) stored in the cache. The default is 1024 bytes (1K). If your content items average a larger size than this, you should consider changing this cache.
Enable	Enables the cache. Mark this checkbox to enable this cache. To disable this cache, unmark the checkbox.