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