Understanding how to size an environment for performance

Answer

The TPAE architecture is a multi tier product where database, application, and client can run separately supported by their own resources. This architecture provides for simple expandability / scalability.

IBM recommends working with the database server provider for best practices in scaling the database tier. DB2, Oracle, and SQL Server will have different recommendations, best practices, and offerings to assist with this process.

The TPAE application runs inside a Java Virtual Machine (JVM). This allows the product to run on multiple platforms including AIX, Windows, Linux, Solaris, and HPUX. A JVM can be either 32 bits or 64 bits and can support resources related to the environment it runs in.

A 32 bit JVM can support up to 2GB of memory but depending on the operating system, may not be able to access more than 1.2 to 1.5 GB. As of TPAE 7.5, production environments can only be supported on 64 bit environments. 32 bit JVMs can process about 250 transactions per minute.

A 64 bit JVM can support much larger blocks of memory than 32 bit JVMs. The recommended minimum memory allocated for a production JVM is 4GB. This will provide about 3.5GB for the application with .5GB in JVM overhead. A 64 bit JVM can process about 375 transactions per minute.

An instance of a TPAE application can be all inclusive or separated into dedicated processes. An all inclusive TPAE application can support up to 35 concurrent user interface (UI) users while performing a light load of background function including cron tasks, escalations, integration, and reporting. A dedicated 64 bit UI JVM can support up to 75 concurrent users with all other function performed on other JVMs. A best practice for production environments is to create one or more dedicated UI JVMs, one or more dedicated cron task/escalation JVMs, one or more dedicated integration JVMs, and one or more dedicated Report JVMs. See the document "Using System Instance Properties to Control Cron Tasks" for more information on dedicating JVMs for specific function.

Using the number of transactions noted above for a 64 bit JVM (375) and the number of likely transactions per minute per user (5) you can calculate the number of concurrent users on a dedicated UI JVM as 375 / 5 = (75).

Cron tasks can be more challenging as it is not only the number of times a cron task runs in a minute but the number of transactions each cron task performs. A cron task that performs 3 transactions and runs 3 times per minute executes 3 * 3 = (9) transactions per minute. If you have 10 crons/escalations that do that then the total would be 90 transactions per minute or about one quarter of the JVM capability.

Integration records can also be difficult to calculate as a single record may require multiple transactions to fully process. A good rule of thumb to start with is to use 1 transaction per record so that processing 600 records per minute would dictate at least 2 dedicated integration JVMs to process that volume.

A good starting point for reporting JVMs is 1 reporting JVM for each 500 concurrent users, however; this is very dependant on report complexity and number of users running concurrent reports. The load on this JVM should be monitored to determine the need to expand.

For production environments, it is recommended that at least 2 UI JVMs be implemented even for light user loads. This provides a basic level of high availability / fault tolerance. If one of the UI JVMs fail, users will still have seamless access to the application through the other.

A typical implementation for 100 concurrent users might look like this:

2 UI JVMs (could support up to 150 concurrent users)

1 Cron JVM

1 Integration JVM

1 Reporting JVM

Each JVM should have 4GB memory non swapped/dedicated physical memory and 1 processor (though depending on the processing power of the processor it may make sense to be more aggressive with this sizing parameter).

The server running the above configuration (if it is all on one server) would require 24GB memory and 6 processor cores. NOTE: The OS will require 4GB memory and 1 processor core.

Note: Because the number of users that can run is only dependant on the number of JVMs running to support the UI, the environment is extremely scalable. If, at some future date, the user community grows, additional JVMs can be added to the cluster to support the load with no change to the code and seamless to the end user. Scaling is only limited by hardware capacity.