Performance Tuning

C H A P T E R 2

Performance Tuning

This section provides tuning suggestions to assist you in obtaining the best performance from your Content Delivery Server system.

This chapter includes the following topics:

Tuning Configuration Variables

Tuning the Oracle Database

Tuning the Application Server

2.1 Tuning Configuration Variables

Configuration variables are used for the database connection pool size, memory settings, and database memory allocations. The values set for these variables can affect the performance of your system.

This section provides some guidelines for setting the configuration variables to improve performance.

2.1.1 Set the Database Connection Pool Size

The following table describes the connection pools used by Content Delivery Server. Pool ID is the string used to identify the pool in the configuration file.

TABLE 2-1 Database Connection Pools
Pool ID	Description
`catalog_pool`	Pool used by for the Catalog Manager and Developer Portal.
`service_pool`	Pool used for the Content Delivery Server services, such as the Event Service, Messaging Service, and ReportService.
`subscriber_pool`	Pool used for the device-based and PC-based Subscriber Portal.
`vending_pool`	Pool used for the Vending Manager. If there is more than one Vending Manager, each Vending Manager has its own connection pool.

Optimal performance is influenced by a number of factors, including the initial number and maximum number of database connections allowed. The $CDS_HOME/deployment/deployment-name/conf/DatabasePools.properties file contains the following properties for managing each pool, where pool-id is one of the pool IDs in TABLE 2-1:

pool-id.db.pool.size.initial - Number of connections initially created for the pool.

pool-id.db.pool.size.max - Maximum number of connections allowed for the pool.

Set these properties according to the guidelines in the following section. Changes take effect when Content Delivery Server is restarted.

2.1.1.1 Determining the Pool Size

To determine the optimal value for each property, consider the following parameters:

For properties prefixed with subscriber_pool, consider:

Number of subscribers accessing the system concurrently

Duration or frequency of subscriber transactions

For properties prefixed with vending_pool, consider:

Number of concurrent Vending Manager administration operations and frequency of operations

Number of concurrent Catalog Manager administration operations and frequency of operations

Frequency of updates to devices, mime types, and content types

For properties prefixed with catalog_pool, consider:

Number of concurrent Catalog Manager administration operations and frequency of operations

Frequency of updates to devices, mime types, and content types (background jobs)

Number of developers accessing the system concurrently and the number of concurrent developer operations

For properties prefixed with service_pool, consider:

Number of subscribers accessing the system concurrently

2.1.1.2 Setting the Sessions Parameter

Each database used for Content Delivery Server schemas must be configured to support the number of connections specified for each schema. Set the sessions parameter for the database to a number greater than the sum of connections specified. For example, given the following assumptions, set the sessions parameter to at least 54:

The Catalog Manager, Vending Manager, Subscriber Portal, and Content Delivery Server services share a database.

The maximum size for the Catalog Manager pool is set to 4.

The maximum sizes for the Vending Manager pool, Subscriber pool, and Services pool are set to 16.

Note - If the server on which the database is running cannot support the number of connections specified and performance is degraded, reduce the connection pool sizes as needed to avoid overloading the database.

Changes take effect when Content Delivery Server is restarted.

2.1.1.3 Troubleshooting

To check whether the configured connection pool size is optimal, add a logger for DBPoolManager by adding the following statement to the $CDS_HOME/cfg/logging.properties file:

cds.DBPoolManager.level = ALL

If any of the following messages appear often in the log file when a Catalog Manager administrator, Vending Manager administrator, developer, or subscriber is accessing the system, it indicates that the maximum pool size is very low and a current thread (call) is waiting for other threads to release the connections:

<0029> Waiting for connection...

<0030> Completed waiting, but still no connections

<0031> Completed waiting, attempting to get connection

Increase the value for the maximum size property based on the guidelines in Section 2.1.1.1, Determining the Pool Size.

2.1.2 Set the Memory Settings

If you are using WebLogic Server and you deployed all components to the same server, Content Delivery Server works well with 50% of a host’s memory assigned to the Java virtual machine. Reduce this value if the host is running database or other resource-intensive processes.

1. Edit the $CDS_HOME/deployment/deployment-name/bin/start_server.sh file.

2. Set the values for the JAVA_MEM variable to half the size of system memory.

For example, if system memory is 2 gigabytes, use the following statement:

export JAVA_MEM=”-ms1024m -mx1024m”

If more than three gigabytes of memory are assigned to the Java virtual machine, the virtual machine must be started in 64-bit mode.

Changes take effect when Content Delivery Server is restarted.

Tip - Change the java.mem property in the deployment configuration file that you use to deploy Content Delivery Server. Updating the configuration file ensures that the desired values are used for future deployments.

2.1.3 Set the Database Memory Allocations

The optimal database configuration is dependent on many factors. Use the information provided in this section as a starting point for your database management and tuning.

For systems with up to 5000 items of content and 50 devices, use the following guidelines for memory allocation:

Set the shared pool size to 2 gigabytes.

Set the buffer cache to 1.5 gigabytes or larger.

For a shared database configuration, use the following guidelines:

Set the Process Global Area (PGA) target using the following equation:

10 megabytes * the maximum number of database connections

See Section 2.1.1, Set the Database Connection Pool Size for information on database connections.

Set the large pool using the following equation:

200 megabytes + the User Global Area (UGA)

UGA = 0.5 megabytes * the maximum number of database connections. See Section 2.1.1, Set the Database Connection Pool Size for information on database connections.

For a dedicated database configuration, use the following guidelines:

Set the Process Global Area (PGA) target using the following equation:

(10 megabytes * the maximum number of database connections) + UGA

UGA = 0.5 megabytes * the maximum number of database connections. See Section 2.1.1, Set the Database Connection Pool Size for information on database connections.

Set the large pool to 200 megabytes.

Set the Java_pool_size parameter to 0.

As more content or devices are added to your system, more memory might be required, especially for the buffer cache. Insufficient memory allocations might result in database error messages or slower performance.

2.2 Tuning the Oracle Database

See the Oracle web site (http://technet.oracle.com) for tips on tuning database performance.

2.3 Tuning the Application Server

Performance might also be improved by tuning your application server.

Set the following properties in the $CDS_HOME/deployment/deployment-name/conf/cache.config file to at least the number of items in the catalog. For example, if the catalog has 10,000 items, set the property to 10000 as shown.

cache.ResourceContentData.threshold=10000

cache.CategoryItem.threshold=10000

Note - You might need to increase the heap size for the Java virtual machine to accommodate the larger cache.

2.3.1 Tuning Sun Java Application Server

If you are using Sun Java System Application Server, disable the dynamic reloading of pages created using JavaServer Pages trademark (JSP) technology by adding the following statements to the $CDS_HOME/deployment/deployment-name/sun/domains/server-domain/applications/j2ee-modules/CDSSubscriberPortal/WEB-INF/sun-web.xml file and the $CDS_HOME/deployment/deployment-name/sun/domains/server-domain/applications/j2ee-modules/CDSFulfillmentManager/WEB-INF/sun-web.xml file.

<jsp-config>
   <property name="reload-interval" value="-1"/>
</jsp-config>

See the Sun Java System Application Server web site (http://wwws.sun.com/software/sunone/) for additional tips on tuning Sun Java System Application Server.

2.3.2 Tuning WebLogic Server

Use the WebLogic Server console to set the following parameters as described:

Set the thread count to 30.

Disable dynamic servlet class reloading by setting Reload Period to -1 for each web application.

If you are using WebLogic Server, disable dynamic reloading of web pages created using JSP technology by following these steps:

1. Change to the $CDS_HOME/deployment/deployment-name/weblogic/domains/domain-name/applications directory.

2. Edit each of the following files and set the param-name element pageCheckSeconds to -1 as shown in CODE EXAMPLE 2-1.

adminconsole/weblogic.xml

developerportal/weblogic.xml

subscriberconsole/weblogic.xml

vsadmin/weblogic.xml

CODE EXAMPLE 2-1 Update to `weblogic.xml`
<jsp-descriptor> <jsp-param> <param-name>pageCheckSeconds</param-name> <param-value>-1</param-value> </jsp-param> <jsp-param> <param-name>keepgenerated</param-name> <param-value>false</param-value> </jsp-param> </jsp-descriptor>

CODE EXAMPLE 2-1 Update to weblogic.xml

<jsp-descriptor>
  <jsp-param>
    <param-name>pageCheckSeconds</param-name>
    <param-value>-1</param-value>
  </jsp-param>
  <jsp-param>
    <param-name>keepgenerated</param-name>
    <param-value>false</param-value>
  </jsp-param>
</jsp-descriptor>

Changes take effect when Content Delivery Server is restarted.

See the WebLogic Server web site (http://www.weblogic.com/) for additional tips on tuning WebLogic Server.