This wiki explains the overall capacity planning methodologies, system requirements, where to find other resources and typical system configurations.
Capacity Planning and Performance Overview
As with any web based platform, the application server and database capacity needed to deploy a system built using IBM TRIRIGA Application Platform largely depends on the number of anticipated users and user requests.
The limits of what is needed are determined by how users are expected to use the system. At a minimum, enough server capacity to satisfy the average load during a work day will be required, with response times that are acceptable to the user base. If possible, strive to satisfy the volume of requests anticipated during peak intervals of high user activity. Hardware resources such as CPU, memory, I/O capacity, and network bandwidth are key to reducing response times. Unless you install IBM TRIRIGA on a server or group of servers that can handle a large number of transactions, users are probably going to experience slow response times.
Adding more servers and database capacity can sometimes improve IBM TRIRIGA's performance, but that is not always the case. The application usage and system configuration can play a significant role in the balance of system performance. Please see the IBM TRIRIGA Application Platform Best Practices for System Performance white paper for more information on tuning the environment.
Sizing & Estimation Methodology
Estimating anything can be a complex and error-prone process. That’s why it's called estimation, rather than a calculation.
There are two primary approaches to sizing a TRIRIGA implementation:
- Size By Example Based
- Proof of Concept Based
A size-by-example (SBE) approach requires a set of known samples to use as data points along the range of system size. The more examples available for SBE, the more accurate the intended implementation will be.
Targeted SBE sizing solutions for prospective TRIRIGA customers are provided in this wiki. These targeted solutions were compiled from our internal deployments, performance benchmarks, and customer's external deployments.
Proof of Concept Based
A proof of concept (POC), or pilot based approach, offers the most accurate sizing data of all approaches.
- Test your implementation design
- Test your chosen hardware platform
- Simulate projected load
- Validate design assumptions
- Validate IBM TRIRIGA
- Provide iterative feedback for your implementation team
- Adjust or validate the implementation decisions made prior to the POC
There is, however, two downsides to a POC based approach, namely time and money. Running a POC requires the customer to have manpower, hardware, and the time available to implement the solution, validate the solution, iterate changes, re-test, and finally analyze the POC findings. A POC is always the best and recommended approach for any sizing exercise. It delivers results that are accurate for the unique implementation of the specific customer that are as close to deploying the real live solution as possible, without the capital outlay on hardware and project resources.