Siebel Performance Tuning Guide > Tuning Siebel Application Object Manager > Guidelines for Siebel Application Object Manager Tuning >

Tuning Parameters for Siebel Application Object Manager Caches

This topic is part of Guidelines for Siebel Application Object Manager Tuning.

The Siebel Application Object Manager uses several caches, which affect memory usage for the Siebel Application Object Manager. Tuning Siebel Application Object Manager caches affects Siebel Application Object Manager performance and memory usage. The following are some of the major caches used by Siebel Application Object Manager that can be configured:

• SQL cursor cache
• SQL data caches

SQL Cursor Cache

The SQL cursor cache is configured using the DSMaxCachedCursors parameter. This cache can be enabled on multithreaded components (such as Siebel Application Object Manager) with database connection pooling.

The value represents the number of SQL cursors per database connection. For a Siebel Application Object Manager for which the Siebel Server computer is more likely to reach its CPU capacity before it reaches its memory capacity (for example, for Siebel Employee Relationship Management), the default value of 16 for the DSMaxCachedCursors parameter might be appropriate. (Such an application is sometimes referred to as CPU-bound.)

For a Siebel Application Object Manager for which the Siebel Server computer is more likely to reach its memory capacity before it reaches its CPU capacity (for example, for Siebel Call Center), you can set DSMaxCachedCursors to a lower value, even to 0. (Such an application is sometimes referred to as memory-bound.)

In general, the value must reflect the CPU and memory resource availability on the Siebel Server computer running a particular Siebel Application Object Manager component. The trade-off in setting this parameter is that allocating memory to caching SQL cursors means they would need to be created less often, but at a cost in memory.

The memory requirement per cursor depends on factors such as the size of the query, type of database connection, row size, and number or rows returned by the query. The utility of these cached cursors depends on the uniqueness of the queries they represent. In general, most Siebel application queries are unique and would not benefit from reusing a cached cursor.

Generally, when more users share a database connection, through connection pooling, you increase the number of cursors cached, provided that the required memory is available. For more information about database connection pooling, see Configuring Database Connection Pooling for Siebel Application Object Managers.

SQL Data Caches

The SQL data caches are configured using the DSMaxCachedDatasetsPerProcess and DSMaxCachedDataSets parameters. Two types of data caches are guided by these parameters:

• Global data cache, which is useful in most cases. This cache is governed by DSMaxCachedDatasetsPerProcess. The default value is 16.
• Per-connection data cache (which can be enabled with, or without, database connection pooling). This cache is governed by DSMaxCachedDataSets. The default value is 16.

For an CPU-bound Siebel Application Object Manager (for example, for Siebel Employee Relationship Management), the default values for DSMaxCachedDatasetsPerProcess and DSMaxCachedDataSets might be appropriate.

For a memory-bound Siebel Application Object Manager (for example, for Siebel Call Center), you can set DSMaxCachedDatasetsPerProcess and DSMaxCachedDataSets to a lower value, even to 0.

In general, the values must reflect the CPU and memory resource availability on the Siebel Server computer running a particular Siebel Application Object Manager component. The trade-off in setting these parameters is that allocating memory to caching SQL data sets means they would need to be created less often, but at a cost in memory. See also the discussion of the SQL cursor cache.