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.

The Cache Reference lists caches that might be used by your portal application. Use the list to assist you in your tuning and 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 Console to Configure Cache Settings

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

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 Adding a Cache from the Cache Reference.

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.

For example, the following content management-related JSP tags include cache-related attributes:

For more information about these JSP tags and their attributes, see WebLogic Portal Javadoc.

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 behavior tracking or individual events. For more information on how to do this, see the Interaction Management Guide.

Tuning for Campaigns

Campaigns are powerful tools for personalization which allow the application to 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.

Asynchronous Campaigns

Setting campaigns to asynchronous can result in better response times for the end user viewing those campaigns. This is done through the AsynchronousEventListener mechanism.

This optimizations is beneficial if the campaign results are not required within the same requests. If the campaign is executed prior to the next request which comes into the server (not necessarily from the user who made the original request) then setting the campaign to asynchronous will help improve the performance of campaigns. For example, if a user were to log in they wouldn’t always see the campaign content placeholder on the screen immediately after the login form but the user would see it prior to their next page change or refresh. Due to the nature of multi-threaded applications the user might see the results on the next immediate screen, but that is not guaranteed.

Setting campaigns to asynchronous does not lower the overall load on the server, but it will lower the response time for the individual requests since the user won’t be waiting for the campaigns to execute in the same thread.

There is a limitation to this however. If the campaign is required within the same request then setting the campaign to asynchronous is not recommended.

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 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 Console.

For more information about how to adjust this setting, see Adjusting Goal Definitions in the Interaction Management Guide.

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 Console to perform the following steps:

Tuning for Entitlements

If you want to cache entitlement information, you need to configure your application to recognize the cache settings. You can do this by editing the netuix-config.xml file.

The netuix-config.xml file resides in the portal web application in the WEB-INF directory.

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 “Portal Web Application Deployment Descriptors” in the Production Operations Guide.

Using Role Caching When Using Entitlements

Role values are cached automatically. However, if you define roles using expressions that utilize dynamic attributes (such as session or request attributes), caching may have little or no value because these expressions are evaluated at runtime. In this case, turning off role caching may improve performance.

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

Tuning for Content Management

Reading and Searching Content

When using search capabilities with content management, it is possible to specify the search criteria used to find a node. Make sure to focus search queries to reduce the total number of nodes returned. This can be done by adding additional query criteria to the search request.

If you are not using the content search capabilities, then turn off this functionality by disabling both Autonomy and searching in the WLP repository configuration. To disable Autonomy, set the environment variable WLP_SEARCH_OPTION=none on server startup. To turn off search in the Content Repository see the Integrating Search Guide.

Pagination has been one focus of performance tuning efforts in the product. If doing pagination over result sets, use one of the objects provided by the Content API. Various options for paging can be found in the Content Management API Javadoc.

The larger the batch size (number of nodes) in a result set, the faster the overall performance will be. Where possible, increase the batch size for a returned result set. See the Capacity Planning Guide for more details on how batch size affects performance.

There are a couple of ways to get access to nodes in the database. The fastest way to retrieve a node is via the node ID. Whenever possible, use this method to retrieve the node. See the Capacity Planning Guide for more details on how different node access types affect performance.

Cache Settings

When you use a WLP repository for your content management system, you can tune the cache settings according to the needs of your portal application. Additional performance recommendations and benchmark data can be found in the Capacity Planning Guide.

You can adjust repository caches by editing Advanced Repository Properties in the Content Management Guide.

You can adjust cache settings for nodes or binaries 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. These settings are configured in the content-config.xml under the application’s META-INF directory.

Tuning for PageFlow Portlets

PageFlow portlets have the potential to significantly increase the memory usage on the server. This is caused by each portlet storing memory both locally and replicating it in the session. Each visible portlet consumes between 500 and 1000 bytes of data either in the local memory or in the session. This is true for each active session accessing the application. This can add up quickly if there are a high number of visible page flow portlets and a high number of active sessions on the server.

Setting the requestAttrPersistence setting on the portlet to transient-session can decrease the amount of data in the session. However, since this data is serialized it will still consume local memory resources. More information about this can be found in the Optimize Page Flow Session Footprint chapter under Designing Portals for Optimal Performance in the Portal Development Guide.

To work around this potential system limitation it is recommended that the number of page flow portlets visible in any given Portal be less than 100 and the memory on the system be increased to deal with the additional overhead.

Tuning for WSRP

For more information about performance guidelines for Web Services Remote Portlets, see Designing for Performance section in the WebLogic Portal Federated Portals Guide.

Clustering for WSRP

When tuning for WSRP, it is important to strike a balance between the number of producer machines and the number of consumer machines. In general WebLogic Portal is CPU bound, meaning that additional CPU resources (usually via clustering) can be used to eliminate bottlenecks. Through performance testing the WSRP infrastructure it is possible to determine whether the producers or the consumer machines are the bottleneck, and then add additional resources as necessary. Depending on the configuration and application it might be necessary to cluster either the consumer or the producer. For more information regarding WSRP architecture refer to the WebLogic Portal Federated Portals Guide. For more information about clustering see the WebLogic Server document Using Weblogic Server Clusters.

Enabling Caches for WSRP

Cache can have an impact on performance, but the size of the portal (determined by the total number of portlets) has the most impact. If you are using WSRP portlets, adjust your caches accordingly. For specific information about WSRP caches, see the WSRP Caches section in the Cache Reference Guide.

Parallel Processing and WSRP

WebLogic Portal has the capability to render portlets in parallel. This is true for WSRP remote portlets as well. If a remote portlet is taking a long time to render, the overall portal may render faster by turning on parallel portlet processing. To enable parallel processing use the forkPreRender attribute of the portlet. See Understanding Portlet Development in the Portlet Development Guide.

Tuning for Delegated Administration

This section explains how to avoid performance problems with the Oracle WebLogic Portal Administration Console when you configure delegated administration roles.

Overview

For each delegated administration role that is configured on a portal resource, several security policies are created (CAN_VIEW, CAN_EDIT, and so on). It is important to note that for each policy that is created, information must be retrieved to perform the required evaluation. As the number of policies increases, the WebLogic Portal Administration Console will perform more and more poorly.

To avoid this poor performance, create as few delegated administration policies as possible.

Best Practice: Limit DA Policies on Resources

When a delegated administration (DA) role is added to a portal resource, such as a content management node or a book node, several security policies are created for each capability, such as CAN_VIEW, CAN_EDIT, and so on). The time taken to retrieve these policies from LDAP and the policy reference information from the database increases as the number of policies increases. Although caching of policy data might improve performance, it is not a secure solution. For instance, if an administrator changed the permissions for a user, the change would not take effect for the user’s session. Other solutions such as flushing the cache and using the session to store information are either technically impractical or not secure.

To achieve the best possible performance, organize your portal resources so that as few as possible DA policies will be created. For example, consider the use case where there are 100 content nodes and you want a particular DA user to only see 10 of those nodes. The best practice is to create a parent node that contains these 10 content nodes and place the DA policies on the parent node only.

Using Work Managers

WebLogic Portal uses WebLogic Server’s CommonJ WorkManager infrastructure for forked portlet pre-render and render. WorkManagers have similar but not identical configuration parameters, behavior, and deployment options. When you upgrade an 8.1.4+ application, any existing customizations to the portalRenderQueue thread pool will not be automatically applied to the default WorkManager used for forking.

To tune this WorkManager, configure a WorkManager and associate it with the name wm/portalRenderQueueWorkManager. For more information about WorkManagers and thread usage in WebLogic Server 10.3, refer to Using Work Managers to Optimize Scheduled Work in the WebLogic Server documentation.