Friday, August 8, 2014

IBM TRIRIGA Application Platform Installation Information

Before you install IBM TRIRIGA Application Platform

Installing IBM TRIRIGA Application Platform

Verification Checklist

Configuring the Platform


IBM TRIRIGA Application Platform Performance Wiki


System Sizing


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

Size-By-Example 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.
POC 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
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.


Topic Categories

·         Hardware Requirements

·         Software Requirements

·         Hardware Configuration

·         Development Environment

·         Basic (Small) Environment

·         Typical (Medium) Environment

·         Advanced (Large) Environment – Coming Soon


Other Resources

·         IBM TRIRIGA Release Notes

·         IBM TRIRIGA Application Platform Compatibility Matrix

·         IBM TRIRIGA Application Platform Version 3 Installation and Implementation Guide

·         IBM TRIRIGA Application Platform Version 3.3 Best Practices for System Performance




Servers

The IBM® TRIRIGA® Application Platform uses many different types of servers. The word "server" is often used to mean a physical piece of equipment, but it can also represent a logical separation that is based on function. Each of these logical servers can be collocated on physical servers, or separated so that each logical tier is installed on their own physical server.

Alternatively, each of these logical tiers can be installed on one or more virtual servers. In turn, these virtual servers can be on a physical server, or a cluster of physical servers in a virtual server cluster.

The following logical function-based servers are used in the IBM TRIRIGA Application Platform:

Web server Receives HTTP requests for web content. Also referred to as a front-end server.

Application server Carries out the user business logic with JBoss Application Server, Red Hat JBoss Enterprise Application Platform, WebLogic Server, or WebSphere® Application Server.

Process server Carries out the background processing and analytics with Red Hat JBoss Enterprise Application Platform, WebLogic Server, or WebSphere Application Server.

Tools server Carries out the reporting. Holds other third-party tools such as Brava! Enterprise Viewer for IBM TRIRIGA.

Database server Holds the relational database and supported database management system such as Oracle Database or Microsoft SQL Server.


Web server
The web server is the tier with which each user web browser communicates. Examples of web servers include IBM HTTP Server, Microsoft Internet Information Services (IIS), and Apache HTTP Server. The web server handles HTTP requests only and does not run business logic. The IBM TRIRIGA Application Platform also supports Secure Sockets Layer (SSL) by using HTTPS. Typically, HTTP uses port 80 (non-secure connection) and 443 (secure connection), but it can be configured to use other ports. Each time a user requests a JavaServer Page (JSP), the web server passes the request to the application server for processing. The web server is a physical manifestation of the web tier.


Application server
The application server is a Java virtual machine (JVM) with an instance of the runtime application. This server runs most of the business logic. Application server processes are CPU-intensive and require a great deal of memory. The application tier consists of JavaServer Pages (JSP) and Java classes. The Java™ 2 Platform, Enterprise Edition (J2EE) application server provides a JSP container, a database connection pool, and transaction management services. The application server is a physical manifestation of the application (middleware) tier.


Process server
The process server is a JVM with an instance of the runtime application that is set up as a dedicated processing or analytics engine. This server is configured almost exactly like an application server, but no users sign on to this server. It handles all workflow requests that are queued from users or by the IBM TRIRIGA software. The process server is a physical manifestation of the application (middleware) tier.


Tools server
The tools server houses the two major third-party extensions from IBM TRIRIGA. This server can run the optional Brava! Enterprise Viewer for IBM TRIRIGA or optional Business Intelligence and Reporting Tools (BIRT) process server or both. You can designate a IBM TRIRIGA application server as a BIRT process server. If you choose to run both BIRT and IBM TRIRIGA on the same server, expect BIRT report handling operations to increase the load on the server. BIRT is run in the same JVM as IBM TRIRIGA in all cases.

Brava is a web-based client-server package that provides view, markup, and collaboration functions. Viewers use a thin client to display documents that are rendered by the server. This process eliminates many compatibility issues and lowers the number of software applications that are needed by users.


Database server

The database server runs the database process. The database is where data is stored. The major database servers use Structured Query Language (SQL) to store and retrieve data. The Oracle Database server and Microsoft SQL Server use SQL. But each server is a different database engine and each has its own extended SQL for competitive differentiation. The application tier communicates with the database tier by using JDBC connection pools. The database server is a physical manifestation of the database tier.

No comments:

Post a Comment