Agent thread levels

You should derive the optimum number of Agent Servers to run and the number of transaction threads for each Agent Server. The throughput of the Agent Server depends on many factors, such as the amount of customization or user exits, data contention, and the size and capacity of the agent servers.

One approach you can use to derive your agent's effective throughput is:

• Allow work to queue up. Make sure there are at least one to two hours worth of work queued up.
• Run a single transaction thread and record the total (running) elapse time.
• Determine the total amount of work performed by the transaction thread for sample monitoring scripts).
• Calculate the effective throughput of that agent thread by dividing total amount of work by elapse time. The throughput rate is specified in terms of work per unit time (e.g., order lines per hour or order lines per minute).

During the test, you should make sure there are no significant system bottlenecks impeding the Agent Server's performance. Some of the performance indicators you should watch for include:

• Excessive JVM garbage collection activities (especially Full GCs)
• Excessive database waits (e.g., I/O, latches, and so forth)
• Inefficient queries (e.g., missing indexes)
• Data lock contention
• Excessive thread synchronization

Make sure the Agent Server is running optimally before calculating its potential throughput rate.

You can schedule multiple agent threads if your average processing level is greater than the effective throughput for a single agent thread. For the reasons mentioned above, more threads (beyond a reasonable level) does not always mean higher throughput.

Excessive agent scheduling

You should not over-aggressively schedule the time-triggered (agent) transactions - for example, configuring a time-triggered transaction to run on many Agent Servers with high threading levels when you expect to a low traffic volume for that transaction. If you schedule the agents too aggressively, you could end up with a situation where the agents (consumers) are outpacing the producers. As a result, the queue typically has a few transactions which are quickly processed. When processed, the Agent Server schedules another getter -- the frequent getter tasks could cause unnecessary overheads as it looks for work to do.

In this case, "more does not necessarily mean more".