Performance Tuning Guide

Tuning Your Portal Domain

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

Tuning Your Domain Configuration

Optimally, when you deploy, you need to create a new domain that is configured for your production environment, including clusters, production configuration settings, and so on.

However, if you have deployed a development domain and want to use it for production, you must change your domain environment settings to optimize performance.

Note: It is not recommended to use a development domain for production, see http://download.oracle.com/docs/cd/E13196_01/platform/docs81/confgwiz/newdom.html#1059076 for more information.

The domain settings are managed by the setDomainEnv.cmd (or setDomainEnv.sh) script which is found in your domain directory. By default, the script is found in: bea-home/user_projects/domain_name/setDomainEnv.cmd/sh.

To edit this file, open it in a text editor.

Table 2-1 lists the start script settings and their appropriate values for a production domain. Remember if you are using a domain that was created for production mode, you do not need to modify the configuration.

Table 2-1 setDomainEnv Settings

Flag Name	Production Mode Setting	Notes
DOMAIN_PRODUCTION_MODE	true	Indicates whether you are in a production mode or a development mode. Default is false for domains created in development mode and true for domains created in production mode.
iterativeDevFlag	false	Checks for updated files, and if found, rebuilds and redeploys the application. Disable this option to prevent checking for changed WebLogic Workshop files. Default is true for domains created in development mode and false for domains created in production mode.
`debugFlag`	false	Used in start scripts to set debugging options and indicate if the WebLogic Workshop Debugger should be started. When switched to false, you save the resource overhead used for debugging. Default is `debugFlag=true` for domains created in development mode; `debugFlag=false` for domains created in production mode.
`testConsoleFlag`	false	Enables the JWS test view. Verify by checking the log for: `wlw. testConsole = false.` Default is true for domains created in development mode; false for domains created in production mode.
`logErrorsToConsoleFlag`	false	Controls logging functionality. Verify by checking the log for: `wlw.logErrorsToConsole = false` Saves you additional logging. The trade-off is that you may see exceptions more easily when this is set to true (without checking the log). Default is true for domains created in development mode and false for domains created in production mode.
`verboseLoggingFlag`	false	If true, override the default `LOG4J_CONFIG_FILE` (`workshopLogCfg.xml`) with `workshopLogCfgVerbose.xml`. Priority value in the default file is `warn`; in the verbose version it is `debug`. Verify by checking the log for: `log4j.configuration = workshopLogCfg.xml` instead of `workshopLogCfgVerbose.xml` You can also start in verbose mode using `startWebLogic.cmd verbose`. Saves you debugging overhead. Default is `false` for both domains created in development mode and in production mode.
`pointbaseFlag=`	false	Indicates whether Pointbase should be started. Verify by checking for a running Pointbase process. Saves you the resource overhead of starting Pointbase when it is not needed. Default is `true` for domains created with Pointbase as the database.

Removing Debugging Tools from Your Domain

When deploying a domain, you should remove the debug.properties file from the domain directory. Although this file is helpful during development, debugging should not be done in production environments.

Tuning for Users and Groups

Note: This feature is available for WebLogic Portal 8.1 SP4 and higher.

If you are using an authentication provider and have a large number of users and groups, it can be beneficial to change the way the Portal Administration tools search for names.

If an authentication provider contains a few thousand groups, you may get better performance in the user management interface by not building a group hierarchy tree for the provider. In the place of a hierarchy tree, you must type the name of a known group in a text box to select that group, as shown in Figure 2-2.

Figure 2-2 Defining a Group Name

Defining a Group Name

Once a group is selected this way, you can add and edit users and set up delegated administration on the group. However, without a group hierarchy tree, you cannot create, delete, or rearrange groups.

Conversely, you can also modify how often the server checks for changes in the hierarchy tree by adjusting the cache sizes. See the online help topic entitled Authentication Hierarchy Service for more information.

Note: In your server startup script(s), you can disable all group hierarchy trees by adding the following to the JAVA_OPTIONS line:

-Dcom.bea.jsptools.disableGroupTree=true