Configuring the mid tier connection pool

This topic provides the following information:

Connecting the mid tier to a load-balanced AR System server group does not require the TCP-binding setting on the load balancer. (For versions prior to version 7.6.04.02, TCP-binding or TCP-sticky is required of the load-balanced configuration so that each client mid tier invokes subsequent API calls to the same AR System server.)

The following independent configurations improve the performance when connecting to a load-balanced AR System server group:

• Connection Pool Settings — Affects the connection pool manager
• Enable Lifespan — Affects the individual connection

Connection Settings page in the Mid Tier Configuration Tool

Modify these settings by using the Mid Tier Configuration Tool instead of directly accessing the config.properties file. Changes made in the UI take effect as soon as you click Save Changes.

Connection pool settings

The connection pool manager manages the creation and destruction of BMC Remedy AR System API connections in its pool. If the mid tier connects to multiple AR System servers or server groups, a pool is created per AR System server or server group, and this setting is a global setting that affects all pools. (From the mid tier’s perspective, a load-balanced server group is logically a single AR System server.) To simplify the pool management process, there is no individual pool configuration.

The pool properties are the following:

• Maximum Connections per Server — The maximum number of BMC Remedy AR System API connections in the pool. This number prevents a runaway condition that an unresponsive AR System server might cause, for example.
• Idle Connections per Server — The minimum number of BMC Remedy AR System API connections available in the pool. When you start the mid tier, until there are enough API calls to reach this number, the pool might not reach this number. In other words, the mid tier does not create this number of connections on startup but only when needed. This is the minimum number of connections in the pool during a low-service period.
• Connection Timeout — The maximum number of minutes a BMC Remedy AR System API connection can stay idle before the manager cleans out the connection. By definition, the manager cannot clean out a connection in the middle of a transaction because the idle time of that connection would be zero.

The following rules worked favorably in BMC load and endurance tests:

• Set Maximum Connections per Server to one-third of the anticipated number of maximum concurrent users. This is the maximum number of simultaneous API calls the mid tier can make to the AR System server or server group. If your user base is a heads-down type (such as in a call center), you might adjust it slightly higher. If your user base is the casual type, you might adjust it slightly lower, but no lower than one-quarter of the anticipated maximum number of concurrent users.
• Leave Idle Connections per Server at the default (5) unless your need is different, such as if you expect to have more than 15 users during a slow period. If your load-balanced configuration does not match the TCP keep-alive setting of the OS that is hosting the AR System server, you might experience stale connections. In this situation, set the OS TCP keep-alive interval to match the load-balanced setting.
• Set Connection Timeout to the TCP idle time setting for your load balancer. The manager then cleans out stale or invalid connections. The default value is 0, which means that each connection in the pool lives forever and is cleaned out only when it becomes invalid. Setting this to a low value affects the JVM heap usage and Garbage Collection (GC) because the JVM needs to create and destroy more connection objects.

Enable Lifespan parameter

The Enable Lifespan parameter is paired with the Connection Lifespan parameter. When you select Enable Lifespan, each AR System connection is created with the expiration indicated by the Connection Lifespan value. On expiration, the connection makes itself available for GC. A connection will not put itself to GC while in the middle of a transaction.

When the numbers of connections in the pool drops, new connections are created as needed in a load-balanced server group environment. A newly created connection is load-balanced possibly to a different AR System server member. Therefore, on the average, the time interval of the Connection Lifespan parameter indicates how often the connections in the pool are re-balanced to all the members in the server group.

Set Connection Lifespan to the lesser of 15 minutes or the server group load-balanced TCP idle time. A smaller value creates additional work for the JVM GC because connection objects are created and destroyed at a faster rate.

In a non-server group environment, the Enable Lifespan parameter is less useful because the connection manager already has the Connection Timeout setting (see Connection pool settings and  https://communities.bmc.com/docs/DOC-61875).

Mid tier logging

Logging provides runtime information and assists you when there is a problem to resolve. Too much logging can affect the performance of the system.

The mid tier has the following logging categories:

• REPORTING
• CACHE
• SESSION
• CONFIG
• FLASHBOARD
• WEBSERVICES
• FIELD
• WORKFLOW
• PERFORMANCE
• EXPRESSION
• SERVLET
• PERFORMANCE
• ARSERVER
• DVMODULE

In a production environment, unless you have a specific issue you want to track down, turn on only the minimal logging:

• arsystem.log_category=PERFORMANCE
• arsystem.log_level=Severe