Introduction

What are the best practices for system performance? Use these best practices to improve the performance of applications on the IBM TRIRIGA Application Platform. While these guidelines provide optimal performance in the lab test environment, your environment might require different settings. The settings in this document can be used as a guideline or as a starting point, and then monitored and tuned to your specific IBM® TRIRIGA® environment.

TRIRIGA has a long and successful history in the world marketplace. Over the years, TRIRIGA has incorporated many new features, grown in complexity, and integrated with other complex software systems. Small, medium, and large organizations implement TRIRIGA in increasingly complex ways. For many customers, TRIRIGA is a global, enterprise-wide implementation with thousands of users.

The larger and more complex the deployment of TRIRIGA is, the more challenging it is for you to keep TRIRIGA performing well for your users. Because some of the greatest challenges are faced by those who deploy these products across large, global enterprises, this document has a special focus on improving performance in advanced enterprise configurations.

The official position of IBM Support is that performance related problems are most commonly the result of environmental factors and outside the scope of support. Although IBM will make every effort to assist our clients in understanding the cause of performance issues, performance related issues are not officially something support can resolve. It is critical that clients fully understand the contents of this best practices document and recognize that failure to adopt the recommendations in this document will prevent further investigation by support in resolving any performance related concerns.

A good technical understanding of TRIRIGA is required to fully understand how TRIRIGA interacts with technology. The Java code that makes up TRIRIGA is called the TRIRIGA Application Platform. It is this code that supports the associated technologies like databases, application servers, and browsers supported for each of the versions IBM releases. Once the Application Platform has been developed, IBM uses the platform to develop TRIRIGA Applications like Lease Management, Space Management, Reservations, Operations and Maintenance, and Project Management. These applications are stored as metadata objects that take advantage of the functionality built into the Development Platform. This metadata that creates applications is stored in the database. We often refer to these to the distinct parts of TRIRIGA as platform and application.

To understand performance tuning with TRIRIGA, you should understand that there are core technology tuning tips that are tied to the platform, and there are application-specific tuning tips related to the metadata coding that creates the applications. Once the network, hardware, and middleware have been optimally tuned, the next step is to tune the TRIRIGA platform and finally the TRIRIGA application. If clients customize workflows or extended formulas, IBM will likely focus first on configurations that may change the use of database indexing, SQL queries, formula usage, data flow, or other aspects that are not consistent with best practices and have not been tested. If custom configurations are identified as a cause of any issue in product functionality or performance, a TRIRIGA developer, business partner, or IBM services engagement may be required to resolve the issue.

The scope of these best practices applies to IBM TRIRIGA 10.x.x and 11.x.x, and IBM TRIRIGA Application Platform 3.x.x and 4.x.x which will be collectively referred to as TRIRIGA in the remainder of these best practices.

The platform version is the smaller number of the two numbers that represent TRIRIGA. The 5.x.x is the platform version and the 11.x.x is the application version. IBM uses a standard of Version, Release, Fix Pack (VRF) as its numbering system so that version 4, release 5, fix pack 3, is 4.5.3. Note that the application version numbers are seven digits larger than platform versions. While many of the recommendations in this document also apply to earlier versions of the TRIRIGA platform and applications, this document is intended specifically for the latest versions.

The platform is always designed to be backward-compatible with applications previously developed. For example, an application is developed by using platform 4.5.0. Upgrading the platform to 5.0.0 maintains compatibility with the older application.

For more information regarding TRIRIGA, see the IBM TRIRIGA product documentation and IBM TRIRIGA Application Platform product documentation in IBM Documentation. Helpful information may be found in the latest Release Notes for your installed IBM TRIRIGA product version, as they may contain specific information that overrides topics in this document. In addition to the release notes, thoroughly review the Installation and Implementation Guide. For information about IBM TRIRIGA supported products and platforms, see the IBM TRIRIGA Supported Versions and IBM TRIRIGA Application Platform Compatibility Matrix.

This information is the result of a cooperative effort between IBM employees, IBM business partners, and a core group of enterprise customers of TRIRIGA. This information was developed both in response to customers and in concert with them. The cooperative effort is ongoing. System performance information that has been developed both within IBM and in actual deployments of TRIRIGA is presented here. The goal of this is to provide you with information that can help you to improve the experience of system performance for your users.

With each release of TRIRIGA, IBM provides new features for your end users. We also strive to increase performance, reliability, and speed with each release. One way that we work to enhance performance is to provide tools and features that are specifically designed to improve system performance.

The IBM Quality Assurance (QA) team does extensive testing of TRIRIGA. Testing is performed during the development cycle, and again, before the product is released. Testing continues after TRIRIGA is released. Application and system functionality testing is performed, as is system performance testing. The quality assurance team tries to emulate many of the kinds of system setups that you might use. However, a laboratory testing environment can never fully anticipate all the scenarios that the product is put through in your environments. The testing environment undergoes constant review to determine how best it can be scaled to meet the demands of large enterprise deployments.

Customer involvement and feedback is vital to improving our quality assurance testing. You can provide feedback for these best practices in our IBM TRIRIGA Chat.

The system performance depends on more than the applications and database. The network architecture affects performance. The application server configuration can hurt or improve performance. The way that you deploy TRIRIGA across servers affects the way the products perform. Many other factors come into play in providing the end-user experience of system performance.

Subsequent sections in this document address the following topics:

• System architecture setup
• Application server configuration
• Reporting
• Integration with other systems using the integration framework
• Network issues
• Bandwidth
• Load balancing
• Database tuning and SQL tuning
• Client workstation configuration
• Miscellaneous performance improvement tips
• Platform tuning
• Application configuration and customization
• Troubleshooting

When planning for a TRIRIGA implementation, it is important to schedule:

• A phase for performance testing
• A phase for performance tuning
• Contingency iterations of testing and tuning for issues discovered
• Fallback plans to mitigate the risk if performance testing uncovers issues

As a part of project management, certified PMPs should be fully versed in project risk management. Project managers should develop a series of actions should identified risks occur. Performance testing and tuning are inherent risks in any implementation. Poor preparation can lead to unrealistic deadlines, and even project failure. It is important to add ample time to perform multiple iterations of performance testing and tuning, and explain to the stakeholders what the risks are, in terms of project deadlines, if they do not accept that there may be multiple iterations and extra time needed to tune the system and application.

It is also important to understand the difference between a contingency plan and fallback plan. A contingency plan is developed to be taken only when identified, accepted risk events occur, and is developed during the plan risk responses process. A fallback plan is developed to deal with risks if the primary contingency plan is not effective, for the known identified risks.

For example, if, in the performance testing phase, a performance issue is identified with a particular process is uncovered. The tuning phase would investigate the performance issue by examining the performance logs generated by executing the process, and analyzing the information for where the bottleneck or hot spot is. Once the analysis is done, the application metadata can be updated, following best practices for application performance. If an application cannot be easily updated, that is when a contingency plan comes into play, where a larger re-architecting of the application would be done to both deliver the business requirements, and solve the performance issues as well. The fallback plan would come into the picture if the re-architecting fails to improve performance, and the initial assumptions of the system size are brought into question, and new faster hardware is required to deliver acceptable performance.

TRIRIGA can be seen as sitting at the apex of a pyramid that consists of network, hardware, and software services. When beginning to troubleshoot any performance issue, it is crucial to consider the entirety of the stack as potential variables that should be diagnosed. If the top is tuned without consideration for the reliant levels below it, the end user result may continue to perform poorly. The pyramid comprises the infrastructure within which TRIRIGA operates, as follows:

• TRIRIGA runs within the layer of software services. The entire system must be sufficiently robust and well-tuned.
• Software services such as application servers, report servers, and database servers run on the operating systems.
• Operating systems run on the hardware servers.
• Hardware servers operate within the network.
• Network architecture supports the entire system infrastructure.

Improving system performance requires attention to all elements of the infrastructure. Your databases can be tuned perfectly, but if the network is slow, you may still have system performance issues. Or, you may have a fast local area network, but if client workstations lack memory and processing power, users experience poor performance.

Customers report that there is normally more than one issue to address. Improving performance involves adjusting many things. Together, these changes can combine to yield significant performance improvement. Making improvements in one or two areas can boost performance. For example, upgrading end-user workstations can often greatly improve the application experience, even if other problems exist in the overall deployed environment. As you continue to improve different areas of the environment, system performance improves incrementally.

The following figure illustrates the interdependence of TRIRIGA and other elements in the system infrastructure pyramid. The remainder of these best practices will discuss performance considerations starting at the base of the pyramid moving up to the top of the pyramid with specific recommendations for the TRIRIGA product.

TRIRIGA Infrastructure Pyramid