Best Practices for System Performance

      

As of February 2017, based on customer feedback, the Best Practices for System Performance document will no longer be updated in PDF format. Instead, its content will be updated in wiki format below. As of November 2017, these best practices were consolidated into fewer pages, reorganized in several chapters, and reformatted with a friendlier look and feel.

What are the best practices for system performance?

Use these best practices to improve the performance of applications on the IBM® TRIRIGA® Application Platform 3.5.x. While these guidelines provide optimal performance in the lab test environment, your environment might require different settings. The settings in this wiki can be used as a guideline or as a starting point, and then monitored and tuned to your specific 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.

Notes:

  • Deployments in virtualized environments such as VMware® might not see the same performance benefits from the recommendations made in these best practices. Using shared resources in virtualized environments is notrecommended for optimal performance. Use dedicated CPU and memory resources instead.
  • In addition, internal testing has shown that putting the TRIRIGA database in a virtualized environment such as VMware can have significant performance impacts. These impacts increase rapidly with larger workloads. While some customers run their TRIRIGA database successfully in a virtual machine, IBM strongly recommends dedicated unvirtualized hardware for optimal performance.
  • If you deploy TRIRIGA on VMware, see the following tuning guides available from VMware:

Table of Contents

  • 1 Introduction

    • 1.1 Support for Performance Related Concerns
    • 1.2 Version Identification
    • 1.3 Product Documentation
    • 1.4 Best Practices as a Cooperative Effort
    • 1.5 Quality Assurance and Testing
    • 1.6 Factors in System Performance
    • 1.7 Performance Testing and Tuning in Implementation Project Plans
    • 1.8 Infrastructure Pyramid
  • 2 Network Considerations

    • 2.1 Network Speed Throughput Test
    • 2.2 Using Citrix or Windows Terminal Server
    • 2.3 Using Compression Techniques to Improve Performance
      • 2.3.1 HTTP Compression
      • 2.3.2 Hardware Compression Using Network Appliances
  • 3 System Architecture and Hardware Considerations

    • 3.1 Scalability Factors
    • 3.2 Basic System Configuration
    • 3.3 Typical System Configuration
    • 3.4 Advanced System Configuration
      • ​3.4.1 IBM TRIRIGA Anywhere Architecture
  • 4 Operating System Configuration

    • 4.1 Server Operating System Configuration
      • 4.1.1 Red Hat Linux Configuration
      • 4.1.2 Windows Configuration
    • 4.2 Client Operating System Configuration
  • 5 Database Server Tuning and Maintenance

    • 5.1 General Database Tuning (was 5.4)
      • 5.1.1 Indexing (was 5.4.1)
      • 5.1.2 Recommended Performance Tuning Indexes (was 5.4.2)
      • 5.1.3 Query Tuning (was 5.4.3, see 7.3.1)
    • 5.2 Database Maintenance (was 5.5)
      • 5.2.1 Database Statistics (was 5.5.1)
      • 5.2.2 Reorganizing Tables and Indexes (was 5.5.2)
      • 5.2.3 Multibyte Character Sets (was 5.5.3)
      • 5.2.4 Archiving and Deleting Historical Data (was 5.5.4)
      • 5.2.5 Tablespaces (was 5.5.7)
      • 5.2.6 Database Server Virtualization (was 5.5.8)
      • 5.2.7 Database Server Throughput (was 5.5.9)
      • 5.2.8 Database Disk-Caching Policies (was 5.5.10)
    • ​​5.3 IBM DB2 Database (was 5.6)
      • 5.3.1 IBM DB2 Database Server Tuning (was 5.2)
        • a. DB2 Automatic Buffer Pool Size and Auto Extends (was 5.5.5)
        • b. DB2 Diagnostic Log (was 5.5.6)
      • ​5.3.2 IBM DB2 Application Platform Indexes (was 5.4.2.a)
      • 5.3.3 Reserve Indexes for DB2 (was 5.4.2.d)
    • 5.4 Oracle Database (was 5.7)
      • 5.4.1 Oracle Database Server Tuning (was 5.1)
        • a. Oracle Licensing Considerations (was 5.1.1)
        • b. Oracle RAC Considerations (was 5.1.2)
      • 5.4.2 Oracle Application Platform Indexes (was 5.4.2.b)
      • 5.4.3 Reserve Indexes for Oracle (was 5.4.2.e)
    • ​​​5.5 Microsoft SQL Server Database (was 5.8)
      • 5.5.1 Microsoft SQL Server Database Server Tuning (was 5.3)
        • a. Server and Memory Considerations (was 5.3.1)
        • b. Snapshot Isolation (was 5.3.2)
        • c. Implicit Conversions (was 5.3.3)
        • d. Sparse Columns (was 5.3.4)
      • ​​5.5.2 Microsoft SQL Server Application Platform Indexes (was 5.4.2.c)
      • 5.5.3 Reserve Indexes for SQL Server (was 5.4.2.f)
  • 6 Application Server Tuning

    • 6.1 General Recommendations
      • 6.1.1 JVM Heap Size Values
      • 6.1.2 Connection Pool
    • 6.2 IBM WebSphere Application Server, Liberty Profile
    • 6.3 IBM WebSphere Application Server, Full Profile (was 6.2)
      • 6.3.1 Generic JVM Arguments (was 6.2.1)
      • 6.3.2 Thread Pool Tuning (was 6.2.2)
      • 6.3.3 IBM DB2 JDBC Data Sources (was 6.2.3)
    • 6.4 IBM HTTP Server (was 6.3)
    • 6.5 Oracle WebLogic Server (was 6.4)
    • 6.6 HTTP Compression (was 6.5)
    • 6.7 Load Balancing (was 6.6)
  • 7 IBM TRIRIGA Tuning

    • 7.1 System Properties
      • 7.1.1 TRIRIGAWEB.properties
      • 7.1.2 Agents
        • a. Agent Locations and Descriptions
        • b. Disabling Agents
        • c. Multiple JVMs Per Server
        • d. Multi-Threaded Agents
        • e. Workflow Agent
        • f. Platform Maintenance Scheduler (Cleanup Agent)
        • g. Extended Formula Agent
    • 7.2 Reserve Performance
      • 7.2.1 Filtering
      • 7.2.2 Empty Filter
      • 7.2.3 Enable Directed Search
      • 7.2.4 Enable Multi-Threading
      • 7.2.5 Debugging Reserve
      • 7.2.6 Performance Indexes
    • 7.3 Query and Report Performance
      • 7.3.1 Query Tuning (was 5.4.3 and 7.3.3)
        • a. Important Tips for Creating Well-Tuned SQL Queries (was 5.4.3.a)
      • 7.3.2 Home Portal and Other Portals (was 5.4.3.c and 7.3.1)
      • 7.3.3 Fields and Extended Formulas (was 7.3.4 and 7.6.1)
      • 7.3.4 Reverse Association Queries (was 5.4.3.b) 
      • 7.3.5 Query Sort Order (was 7.3.2)
      • 7.3.6 Using Report Run History to Track Query Performance (was 5.4.3.e)
      • 7.3.7 Advanced Reporting (BIRT) (was 7.3.5)
        • a. BIRT Report Offloading
        • b. Queued Reports (Asynchronous)
        • c. Maximum Available Server Memory
    • 7.4 Workflow Performance
      • 7.4.1 Workflow Instance Data
      • 7.4.2 Workflow Optimization
      • 7.4.3 Workflow Analysis Utility
    • 7.5 Integration Framework
      • 7.5.1 Integration Workflow Processing and Performance
        • a. Disabling Workflows Unused by an Operation
        • b. Limiting the Number of Workflow Agents
    • 7.6 Graphics Section Performance (was 7.7)
      • 7.6.1 Drawing Size (was 7.7.1)
      • 7.6.2 Graphic Layer Config (was 7.7.2)
      • 7.6.3 Simplifying Drawings (was 7.7.3)
        • a. CAD Commands
        • b. Manual Editing and Cleanup
      • 7.6.4 Summary (was 7.7.4)
  • 8 IBM TRIRIGA Anywhere Tuning

    • 8.1 IBM MobileFirst Server
      • 8.1.1 IBM WebSphere Application Server
        • a. JVM Heap Size Values
        • b. Generic JVM Arguments
        • c. Thread Pool Tuning
      • 8.1.2 IBM HTTP Server
    • 8.2 IBM TRIRIGA Integration Process Server
    • 8.3 IBM TRIRIGA Anywhere Work Task Management
      • 8.3.1 System Properties
      • 8.3.2 Security Groups and Licenses
    • 8.4 Device Considerations
  • 9 Troubleshooting and Monitoring Performance

    • 9.1 Troubleshooting Performance Problems
      • 9.1.1 Setting Up a Standalone Application Server for Debugging
      • 9.1.2 WebSphere Performance Monitoring Infrastructure (PMI)
      • 9.1.3 IBM TRIRIGA Application Platform Logging
      • 9.1.4 Displaying Garbage Collection Statistics on the Server
      • 9.1.5 Applying the Latest Patches
    • 9.2 Performance Problem Determination
      • 9.2.1 Problem Determination Techniques
        • a. Application Server
        • b. Web Server
        • c. Database Server
        • d. Network
        • e. CPU
        • f. Memory
      • 9.2.2 Problem Determination Tools
        • a. IBM TRIRIGA Application Platform Tools
        • b. Heap Dump, Thread Dump, and Garbage Collection Utilities
        • c. Application Profiling Utilities
        • d. Database Utilities
    • 9.3 Monitoring the System
      • 9.3.1 Monitoring Tools
        • a. Middleware Monitoring Tools
        • b. System Resource Monitoring Tools
        • c. Bandwidth Monitoring Tools
  • 10 Information Gathering for Support

Next >