Cognos 10.2.2 Performance Tuning - Senturus


Cognos 10.2.2 Performance Tuning

June 18, 2015

Deployments & Performance Optimizations, IBM Analytics & Cognos

Best Practices for Optimizing Your Investment

Performance Tuning 

Learn proven practices and industry standards for setting up your Cognos servers to handle anything you can throw at it. In this webinar recording, we focus on how to fine-tune the following different aspects of the Cognos environment to maximize the platform’s potential:

  • Hardware-based performance: Hardware to procure for servers, virtual vs. physical servers and how to structure your environment
  • Cognos server tuning: Settings to adjust, establishing enough resources to handle concurrent user base
  • 64/32-bit: Determining which one is right for your organization, using 64-bit advantages
  • Data tuning: Determining when a data warehouse is needed, tackling bottlenecks, Dynamic Cubes and PowerCubes

Discover how to get the most out of your Cognos investment.


Todd Schuman
Cognos Architect
Senturus, Inc


Hardware Performance

  • Sizing Up Servers: Processors, Sockets, and Cores
    • Processes
      • An independent program running on a computer. A process has a full stack of memory associated for its own use, and does not depend on another process for execution.
    • Thread
      • A thread is essentially a process that does not have a full stack of memory associated for it. The thread is tied to a parent process, and is merely an offshoot of execution. Typically thread processes must run on the same computer, but can execute simultaneously on separate cores of the same node.
    • Hyper-threading
      • Hyper-threading is an Intel technology that originally preceded multi-core systems, and was used to make a single core appear logically as multiple cores on the same chip. Intel abandoned hyper-threading briefly during the advent of multi-core processors but reintroduced the technology in 2008. Since then, Intel has used it extensively to improve the performance of parallel computations in its multi-core processors. Hyper-threading improves performance by sharing the computational workload between multiple cores whenever possible, allowing the operating system to schedule more than one process at a time.
  • Adjusting RAM
    • Use the following memory settings as a starting point and adjust them based on the memory usage of your system.
      • 2 GB for the base operating system and accompanying software, such as antivirus, back up, and enterprise management software
      • 4 GB for a 64-bit Content Manager JVM
      • 4 GB for a 64-bit Application Tier JVM
      • 2 GB for the graphics JVM (IBM Cognos Workspace)
      • 2-4 GB for the query service (dynamic query mode) JVM
      • 1 GB per core for the report services processes (dynamic query mode) (JVM)
      • 2 GB per core for the report services processes (compatible query mode) (BIBuS)
    • Note: Dual Core, 64-bit Single Server needs 16GB for CQM
  • Distributed Environments
    • Load balancing
    • Fail over
    • Hardware aligned for specific Cognos needs
    • Scalable
  • Virtual vs. Physical Servers
    • Pros
      • Reduced maintenance on physical servers
      • Easily allocate additional resources
    • Cons
      • Overhead: 5-10%
      • Dedicated resources

Cognos Server Tuning

  • Concurrent Users
    • 100:10:1 Rule
    • 100 Named Users
    • 10 Active Users
    • 1 Concurrent User
    • 4,000 Named Users = 40 Concurrent Users
  • Dispatcher Tuning
    • 93 Tuning Categories!
    • Batch Report Processes
    • 1 * # CPU Cores, 2GB CQM, 1GB DQM
    • Interactive Report Process
    • 2 * # CPU Cores, 2GB CQM, 1GB DQM
  • Dispatcher Requests
    • High Affinity Tasks
      • Report Viewer links (Run again, Return)
      • HTML report navigation(Top page, Page up, Page down, Bottom page
      • Delivery options(Save, Save As, Print, Email, Viewing)
    • Low Affinity Tasks
      • Report Querying(Reporting, Report Processing)
      • Report Authoring(Metadata Retrieval, Query Validation)
      • Administrative(Testing Data Source Connections, Adding Objects (Folders, Jobs, Schedules, etc.), Refreshing Portal Page)
    • Peak/Non-Peak Hours
  • WebSphere Liberty Profile
    • To reduce the startup time, memory footprint, and resources used, use the default setting of 768.
    • To balance between fast startup time and quick operating speeds, type a value about 1.5 times the default value, such as 1152.
    • To maximize operating speeds and if performance is more important than fast startup time, and if your computer has a lot of resources, type a value about double the default value, such as 1536.
  • Quick Fixes
    • ISAPI instead of CGI
      • Improved management of multiple users
    • IIS – Content Expiration
      • COG_ROOT>/webcontent/pat/images
      • 600+ Images
      • Set HTTP Response Headers
      • Common Headers
      • Expire Web Content
    • Dynamic Query Mode (DQM)
      • Not using DMQ? Turn off Query Service to gain 1GB RAM each server


  • Performance and Scalability Testing
    • End-User Transactions and Load Generation Tools
      • IBM Rational Performance Tester
      • HP Loadrunner
      • Telerik Test Studio (previously Fiddler)
    • Server Resource Tools
      • Microsoft’s SysInternals Tools (Windows)
      • Microsoft’s Performance Monitor (Windows)
      • NMon (AIX and Linux)
      • ‘top’ and ‘ps’ (Linux and UNIX)

64-bit and Data / Report Tuning

  • 64-bit Advantages
    • Access more memory
    • 64-bit registers allow faster, more efficient execution
    • Stability
  • DQM / Dynamic Cubes
    • In-memory Aggregation
    • Relational DMR
  • Run DQM
    • Install JDBC Drivers
    • Enable JDBC Connections
    • Enable JDBC in Framework Manager
    • Beyond PowerPlay: Choosing OLAP
    • Dynamic Cubes in 10.2
    • IBM Cognos Dynamic Cube Deep Dive
  • Star Schema
    • Less join paths
    • Allows quick understanding, navigation, and analysis of large, multidimensional data sets
    • Flexibility
  • Summary Tables
    • Pros
      • Eliminate need for large, on-the-fly aggregation of large tables
      • Fast performance
    • Cons
      • Requires DBA / maintenance
      • Built at only one level of aggregation
  • Power Cubes
    • Pros
      • Drill up / down
      • Aggregation at every dimension
      • Cognos dimensional functions
    •  Cons
      • File size
      • Latency
      • Build time
  • Other Performance Causes
    • Reporting Design
    • Database Performance
    • Network / Firewall
    • Stitched Queries
    • Local Processing
    • Infinite Others