3. System Architecture and Hardware

This section addresses ways to maximize system performance by configuring your system architecture to account for your resource needs. Note that when evaluating sizing for your TRIRIGA system, it is important to include a performance test phase as part of the implementation. This section contains sample starting configurations, but it is crucial that performance testing analysis and tuning be conducted to reach the optimal configuration for your unique environmental and application circumstances prior to signing off on the final production configuration.

For more details on system architecture and hardware configuration, see the Installation and Implementation Guide.

As with any web-based platform, the application server and database capacity that is needed to deploy the TRIRIGA system implementation depends largely 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, the server capacity to satisfy the average load during a work day is required, with response times that are acceptable to the user base. If possible, aim to satisfy the volume of requests that is 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 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 TRIRIGA 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.

Estimating the TRIRIGA system size can be a complex and error-prone process. That’s why it's called an estimation, rather than a calculation. There are two primary estimation methodologies to sizing a TRIRIGA implementation: (1) Size by Example, and (2) Proof of Concept.

3.2.1 Size by Example

A Size by Example (SBE) approach requires a set of known samples to use as data points along the range of system sizes. By making more examples available for SBE, the intended implementation will be more accurate. Several targeted SBE sizing solutions for prospective TRIRIGA customers are provided below. These targeted solutions were compiled from our internal deployments, performance benchmarks, and our customers' external deployments.

3.2.2 Proof of Concept

A Proof of Concept (POC) or pilot-based approach offers the most accurate sizing data of all approaches. Here are the steps:

• 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.

However, there are two downsides to a POC-based approach, namely, time and money. Running a POC requires the customer to have the manpower, hardware, and time available to implement the solution, validate the solution, iterate changes, retest, and finally analyze the POC findings. Nonetheless, 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, and that are as close to deploying the real live solution as possible, without the full capital spending on hardware and project resources.

Many factors can affect the scalability of TRIRIGA. For example, the type of hardware used can determine how many active users per Java virtual machine (JVM) you will be able to achieve.

The average workload that is applied to the system can also have a large impact on the system. For example, you can support more users per JVM if those users are producing five transactions per hour as opposed to ten transactions per hour. In addition, heavily customizing TRIRIGA can result in fewer users per JVM due to the overhead in processing custom code.

Lastly, the architecture used in deploying TRIRIGA has a significant impact on the number of active users per JVM. Some clients achieve only 50-100 concurrent users per JVM when all transactions (both front-end and back-end) are running in the JVMs, as described in the basic system configuration section. Creating separate JVMs for user interface transactions allows for more active users per JVM, as described in the typical system configuration section. In an advanced system configuration, internal testing shows the ability to support up to 2000 concurrent users per user interface JVM.

A development environment is typically used as a sandbox for developers to make and test changes. This sandbox type environment is not usually built for performance or for a large number of users. This is also known as a basic system configuration that typically has less than 20 concurrent users.

A typical configuration for this type of environment would only have 1-2 tiers depending on the database requirements. A single application tier/server is common to serve for multiple logical roles in this case, e.g., application, process and BIRT server.

Below is a list of typical hardware requirements for the application tier used for this configuration:

• 2 - 4 CPU logical cores/threads
• 4 - 8 GB of memory with 4 GB allocated to the Java heap

A basic or small environment might be a configuration for production with less than 100 concurrent users or a staging environment for a lower than production user count but not used for development work. In other words, this type of environment might be configured for production performance or for production functionality testing. This is also known as a basic system configuration that typically has less than 100 concurrent users.

A basic configuration consists of TRIRIGA running on a single application server. The application server connects to a single instance of the database that is available on a database server. The application server can also connect to a report server.

The basic system configuration is not typically recommended if the use of IBM TRIRIGA Connector for Business Applications (Web Services) is expected. TRIRIGA applications that use IBM TRIRIGA Connector for Business Applications or other connector technology may require more server resources and therefore should not be used in a production environment if the basic system configuration is implemented. Examples of connector-based products are TRIRIGA CAD Integrator, Reservation Management with Microsoft Exchange, ENERGY STAR Connector, Connector for ESRI/GIS and the TRIRIGA Integration Object.

A typical configuration for this type of environment would only have 2 tiers, one for the application server and the other for the database. A single application tier/server is common to serve for multiple logical roles in this case, e.g., application, process and BIRT server. If given the choice of two different types of servers, the more powerful server should be the database server. The most common way to improve performance of a TRIRIGA system is to increase the CPU and memory size of the database. The database server is the single most important server across the tiers.

Below is a list of typical hardware requirements for the application tier used for this configuration:

• 2 - 4 CPU logical cores/threads
• 4 - 8 GB of memory with 4 GB allocated to the Java heap

Example of Basic System Configuration

A typical or medium environment might be a configuration for production with less than 1000 concurrent users or a staging environment for a lower than production user count and does not have redundancy nor high availability (HA) requirements.

A typical configuration for this type of environment would only have 2-3 tiers, depending on infrastructure and security requirements. A web tier might be added for a DMZ requirement, but the typical configuration is to have one tier for the application servers and the other for the database. The most common way to improve performance of a TRIRIGA system is to increase the CPU and memory size of the database. The database server is the single most important server across the tiers.

Another way to improve performance is to utilize separate JVMs for the logical application and process servers. TRIRIGA application and process servers have the same installation and have the same Java Application Server requirements; they just serve different roles for the system. The application server, single or multiple, is for user sessions and should be dedicated only to users with no background processes. The process server, single or multiple, should be dedicated to background processes, like agents, integrations, and advanced reporting processing.

Below is a list of typical hardware requirements for the application tier used for this configuration:

• 4 - 8 CPU logical cores/threads
• 8 - 16 GB of memory with 4 GB allocated to each Java heap
• 50 GB disk drive

Below is a list of typical hardware requirements for the database tier used for this configuration:

• 8 - 16 CPU logical cores/threads
• 16 - 32 GB of memory
• 500 GB of fast Fibre Channel 15K RPM (or faster) disk or solid state drives

The following figure shows a typical configuration to support a system that has less than 1000 concurrent users expected and no advanced system needs such as high availability (HA).

Example of Typical System Configuration

An advanced or large environment might be a configuration for production with up to several thousand concurrent users and when redundancy or high availability (HA) requirements are crucial to business needs.

An advanced system configuration may have one or more of the following requirements: high availability, load balancing, integrations, or high number of concurrent users to name a few. This type of advanced system setup might be as simple as two application servers with a cold failover clustered database system, or as extreme as multiple servers at all tiers. Implementations of TRIRIGA for advanced system needs can be achieved in many ways depending on the requirements of your system. There are no hard requirements for the TRIRIGA Application Platform to achieve these types of advanced requirements.

High availability (HA) requirements can be configured many ways. Hardware-based or software-based load balancers can be used in front of multiple web servers to communicate with multiple application servers. With the use of the IBM TRIRIGA Administrator Console, the logical roles of the servers can be changed dynamically at any time by turning background agents on or off with any server console.

Continually monitoring and evaluating TRIRIGA products for performance in conjunction with using horizontal and/or vertical scaling is an effective way to distribute user load, improve overall system performance, and ensure optimal end user experience. With WebSphere Liberty Collectives, HTTP Session Failover can be used for both high availability and load balancing. Hardware- or software-based load balancers can be utilized to distribute workloads among multiple web servers to communicate with multiple application servers. If a multi-server environment is configured at the application server tier using WAS Full Profile, it is not recommended to use session failover. With load balanced web servers, session affinity (sticky sessions) should be utilized. As such, the client’s request will always be passed through the same server that originated the request and overhead associated with replicating session data can be eliminated.

The number and type of servers used in a high availability environment depends largely on application usage patterns and production transaction volumes. The number and size of JVMs configured depends in part on the overall hardware and software limitations of the environment, as well as on the expected number of concurrent users. You can tune the setup based on traffic and performance numbers. For example, in situations in which many web services or integrations are exercised via APIs, a dedicated TRIRIGA integration server may be necessary to maintain system performance. However, the database server should still be the largest and most important server in the environment. One application server could easily overwhelm the database server with work to perform.

Below is a list of typical hardware requirements for the application tier used for this configuration:

• 8 - 16 CPU logical cores/threads
• 16 - 32 GB of memory
• 50 GB disk drive

Below is a list of typical hardware requirements for the database tier used for this configuration:

• 32 - 64 CPU logical cores/threads
• 64 - 256 GB of memory (SQL Server should be configured with larger sizes)
• 2 - 4 TB of fast Fibre Channel SAN storage with 15K RPM (or faster) disk or solid state drives

The following figure shows an example of the type of complex enterprise architecture to support up to several thousand concurrent users and when redundancy or high availability (HA) requirements are crucial to business needs.

Example of Advanced System Configuration