Generally speaking, the more powerful the driver and emulator systems are, the less we need to worry about their impact on application-server performance. Even when a reasonably powerful computer is used for the driver and the emulator, however, attention is still required to monitor the driver to make sure it is not the bottleneck.

First, the default number of agents used for both manufacturing and orders were set to 1. These default values are designed for the initial setup of the workload, and they are inadequate for workloads running at hundreds of injection rates. Furthermore, we found that running the driver agents on Windows was limited to about 2000 threads per agent, while each agent was running as a Java process itself. Doing a simple division tells us that a new orders agent needs to be used for roughly every 400 injection rates, and a new manufacturing agent needs to be used for roughly every 660 injection rates. They are different due to the ratio of threads spawned for these transactions. While tuning the agents used on the driver, key PERFMON statistics such as processor queue length, number of threads and processes on the system, and memory utilization must be monitored carefully, as these are all highly contended by the many agent processes and threads.

Three kinds of driver agents–orders, manufacturing, and the large order line–compete for memory on the driver box. Performance can suffer orders of magnitude if insufficient heap memory is used. We found that “-Xms512m –Xmx512m” are reasonable JVM parameters to make sure each agent will always have 512MB of memory at its disposal. Since the machine has 4GB of memory, the maximum number of agents we can practically use is going to be around three orders, three manufacturing, and one large order line, for a maximum capacity of about 1200 injection rate. Such driver capacity limits the performance that can be observed. If higher performance needs to be measured, increasing the use of more physical memory and more system resources, or increasing the number of drivers should be evaluated.

GC activities for the driver agents should be monitored, as excessive GC activities may limit the response time of the transactions and thus limit the performance that can be measured on the application server. GC activities can be monitored using PERFMON if JRockit is used or by using JVM parameters such as “–verbose:gc”.

We have not found the emulator to be in any critical performance path during our study. Therefore, we stayed with the WebLogic configuration for the emulator.