Bookshelf Home | Contents | Index | PDF     

Performance Tuning Guide > Tuning the Siebel Application Object Manager for Performance > Configuring Database Connection Pooling for AOMs >

Database Connection Pooling Usage Guidelines

Observe the following guidelines to help you determine if you should use database connection pooling, or to guide your deployment of connection pooling.

For more information about configuring the AOM parameters for database connection pooling mentioned below, see Configuring Pooling for Default Database Connections and Configuring Pooling for Specialized Database Connections.

When to Consider Using Database Connection Pooling

You should consider implementing database connection pooling if, and only if, one or more of the following is true for your deployment:

  • The RDBMS cannot support the number of dedicated user connections you would require if using nonpooled database connections. Pooling default database connections for shared use can reduce the number of connections you require.
  • Memory resources are scarce on the Siebel Server machine on which the AOM is running. Pooling default database connections for shared use can reduce AOM memory requirements per concurrent user.
  • Your deployment uses external authentication such as LDAP (that is, other than database authentication), and creating new connections is slow on the database server. Pooling database connections can speed up login or other operations by providing persistent pooling—whether or not connections are also shared.
  • You are using a Siebel Server component that requires frequent logins for special-purpose processing. Pooling database connections to provide persistent connection pooling (not sharing) may provide a significant benefit for such components.
    • For Siebel Configurator, if you are using the component Siebel Product Configurator Object Manager (alias eProdCfgObjMgr), it is highly recommended to configure persistent connection pooling. For more information about Siebel Configurator, see Tuning Siebel Configurator for Performance.
    • For some other components, such as EAI Object Manager (when run in sessionless mode), it may also be helpful to configure persistent connection pooling.

      NOTE:  If session caching is configured for a component (by setting the parameter ModelCacheMax), persistent connection pooling may provide little benefit. For example, session caching is typically configured for Workflow Process Manager. For more information about session caching for Siebel Workflow, see Caching Sessions.

Guidelines for Using Database Connection Pooling

If you decide to use database connection pooling, observe the following guidelines:

  • Start with a low ratio of MaxTasks/MaxSharedDbConns, such as 2:1.

    NOTE:  If you plan to use a ratio higher than 3:1, it is recommended that you consult Siebel Expert Services.

  • If you have short (aggressive) average think times in your user scenarios, use a smaller ratio of MaxTasks/MaxSharedDbConns. Longer think times may support larger ratios.

    For a 30-second think time, do not use a ratio higher than 10:1. For a 15-second think time, do not use a ratio higher than 5:1. Other factors discussed in this section will also determine practical limits.

    For more information about think time, see Performance Factors for AOM Deployments.

  • Minimize long-running queries. When multiple user sessions are assigned to a shared default database connection, all database operations from these users go through this shared connection. A database connection can process only one database operation at any particular moment. Therefore, when database connections are shared by two or more users, one user's long-running query may block another user who shares that database connection.

    For example, if a long-running query is run which takes, for example, three seconds, then, for this duration, database requests from other users sharing the same database connection would be queued (blocked) until the query operation completes.

    A long-running query may continue to run on the RDBMS even if the user who initiated it has killed the browser.

    When using database connection pooling, it is critical to optimize database access in your environment. If long-running queries cannot be avoided, monitor the overall database response time and use a small MaxTasks/MaxSharedDbConns ratio to achieve a satisfactory response time.

    Alternatively, long-running queries may be minimized or avoided by adjusting indexes to include fields that may be sorted or queried by end users, by configuring the application user interface so non-indexed fields are not exposed, or by training users to avoid operations that would perform long-running queries. For more information about how indexing can affect Siebel application performance, see Managing Database Indexes in Sorting and Searching.

  • Consider the cost of creating database connections. This cost will differ based on your authentication method.

    If your deployment uses database authentication, a database connection is created for each login, for authentication purposes. Afterwards, this connection is released to the shared connection pool, if the total number of connections is less than the maximum. Or, if the pool is full, the connection is closed (terminated). Therefore, even when the pool is full and connections are available, new connections are still created temporarily for each new session login. These connections must be accounted for in determining the allocation of database connections.

    With external authentication, however, you can use persistent connection pooling to reduce the cost of creating database connections. With persistent connection pooling, database connections, once created, are persistent, though such connections may or may not be shared. For pooled default database connections where connections are persistent but not shared, set MaxSharedDbConns = MaxTasks - 1.

    For more information about authentication options, see Security Guide for Siebel eBusiness Applications.

  • In order to configure connection pooling for specialized database connections, you must also configure pooling for default database connections, as follows:
    • If you do not configure connection pooling for shared database connections (MaxSharedDbConns = -1 or 0), then each specialized database connection, once created, is dedicated to the user session. The value of MinTrxDbConns is ignored.
    • If you configure connection pooling for shared database connections (MaxSharedDbConns has a value greater than 0, and less than MaxTasks), then specialized database connections are not dedicated to user sessions. Such connections are handled according to the setting of MinTrxDbConns:
      • If MinTrxDbConns = -1 or 0, then, after the transaction that required it has ended, each specialized database connection is closed (deleted).
      • If MinTrxDbConns has a value greater than 0, then, after the transaction that required it has ended, each specialized database connection may return to the connection pool.
  • Siebel database connection pooling cannot be used simultaneously with MTS or Multiplexing features of Oracle Net8.
    
Performance Tuning Guide