Estimating Database Connections

Database connections required for a Maximo system can be estimated for each of the categories listed below, then summed up and the sum increased by 10-20% to account for possible underestimates.

Many of these utilize values that will fluctuate over time (for example: peak logged in users) both in the short term (more users and reports at end of month processing) and long term (more users from rollouts or increased use of system). These estimates will serve as a good starting point, but best practice is to also monitor connection use and track its trending.


1. Base Connections Per JVM

For each JVM in each cluster or stand-alone there will be 1 heartbeat connection plus a number of connections in the connection manager's available pool. The size of the latter is controlled by the properties:

mxe.db.minFreeConnections - minimum number of available connections in the pool
mxe.db.maxFreeConnections - maximum number of available connections in the pool

If you have specified different values in the maximo.properties files for the UI cluster and the other standalones or clusters you will need to make separate calculations and sum them up.

Estimate: (1 + mxe.db.maxFreeConnections) * number of JVMs

For an explanation of the mxe.db.* connection properties, please see technote:

Explanation of Maximo Application Server Connection Pooling and Management


2. Connections Per Logged in User

Only one connection is utilized by a logged in user's JVM session.

Estimate: 1 * (peak number of logged in users)


3. Crontasks and Escalations

A running crontask or escalation utilizes a single database connection, effectively the same as a user without the UI. The connection is obtained when the crontask or escalation starts and is returned to the pool before it exits. The number of connections used by these at a given instant is equal to the number running at that instant. For example, if there are only 6 escalations and they are set to run at 5, 10, 15, 20, 30, and 60 minute intervals then all 6 would run on the hour utilizing 6 connections, 4 on the half hour, 3 at the 20 and 40 minute marks, 2 at the 15 and 45 minute marks, and 1 at the 5, 25, 35, and 55 minute marks. You should use the peak number of 6 in this example.

For large numbers of crontasks and escalations running at a wide range of set intervals or at specific times, it can be a very complicated process to determine the peak. Easier to assume one connection per active crontask and escalation.

Estimate: 1 * (total number of active crontasks and escalations)


4. Reports

Each report utilizes at least one database connection, although a report can be designed to use more than one connection when it runs. The only predictable use of connections by reports is for those reports scheduled to run on a regular basis. Most reports are run on an ad-hoc basis which makes it difficult to estimate. You have to poll the user community to determine how many reports are generated per day and how they are distributed across the day.

Estimate: No formula. Must estimate max number of reports that may run at the same time.


5. Integration

Integration processing utilizes one connection for each simultaneous message being processed inbound. This would be 1 for each inbound sequential queue and 1 for each consumer defined for each continuous queue. Sequential queues are processed by crontasks and their connections have been accounted for in #3 above.

Each continuous queue with it's accompanying exception destination queue typically have 5 consumers, for a total of 10 connections at peak load with peak error load. This should be doubled to account for the separate connections used by the JMS queues for the message store in the database. (Do not double if using a file store for JMS queues.)

Outbound transaction utilize the user's connection to generate the transaction.

Interface table processing (if used) is another crontask or more, accounted for above.

Estimate: 20 * (number of continuous queue plus exception destination queue pairs)


6. Other

Connections made from other systems, such as a financial system writing to interface tables in the Maximo schema, External reporting systems, etc. must be estimated and added to the total.

Note: This is also application to MAS Manage.