| Simple Adjustments to Increase Performance and Capacity |
|
Article taken from BSP Newsletter 052, April 2011 The question is always asked "How can I improve performance on my Cognos environment?" Unfortunately the generic answer seems to always be "It Depends..." Without completing a full stress test to analyze load and user behavior on your environment, there are a few configurations that can be analyzed and tested to improve performance. This article will highlight some system configuration settings and reference some load balancing techniques. A few basic questions that should be answered when approaching the tuning of the environment 1.How many users are on the system at peak time? 2.When are batch or scheduled reports run and how often? 3.Are there any reports that are run with frequency that are known to take a long time to complete? A full analysis of the user patterns can be performed to detail specifics with regards to latency, dispatcher routing, local processing, errors, ad-hoc usage and scheduling that will more acutely estimate processing capacity. For this article, the scope will be to detail a few configuration settings that can be modified to assist with performance or increase capacity. Please reference the Cognos Installation and Configuration guide for more detailed descriptions on the topics referenced in this article. Report and Batch Services Report and Batch Services are the two main report types run within Cognos that can be configured in the Administration area on the Cognos Portal. IBM Cognos Administration > Configuration > Dispatchers and Services > Dispatcher X > More > Settings  The report process correlates to any report that is run on demand and the batch process is any report that is scheduled or run in the background. The period’s peak and non peak can be adjusted to correspond with user activity of business hours. Cognos will by default try to run as many reports as permitted, utilizing all available resources, to complete the task as fast as possible. These settings are designed to prevent a Denial of Service (DOS) behavior from occurring. If too many reports are generated per dispatcher in tandem, the system will become overwhelmed with requests potentially resulting in errors and a poor user experience. In addition processes such as report creation and end user navigation will suffer as all available processing will be consumed. The desired experience is that the report and batch processes be balanced per dispatcher based on server configuration. A query that is requested when all processes are busy will be placed in a queue and wait for a process to become available. This methodology when balanced properly will allow the greatest throughput without report errors. Based upon the types of reports requested and time of day, a customized balance of report and batch processes can be configured. The Cognos configuration will default to two processes for both report and batch upon install. The starting recommended settings is to have 1 process * number of processor cores for a dedicated dispatcher. This in turn will dictate the amount of BIBUS processes that are started on each server. Analysis of end user behavior, scheduled reports, and report completion time needs to be factored in to properly adjusting the amount of processes to configure for both report and batch. One method to easily analyze load on your server(s) is to view during your known busiest time the Status panel with IBM Cognos Configuration.  You will be able to view if any reports are in “Waiting” status. This will translate to the reports that are placed in “queue” waiting for a report process to be available. The next most commonly asked question is “Does a report process correlate with a single report?”. The answer is actually a factor of how many services for either report or batch multiplied by the number of connections defined for each type of service. In the administration panel these are defined as Affinity Connections.  In the example above there are 2 report processes so connections will be •2 x 4 Low Affinity = 8 connections •2 x 1 High Affinity = 2 connections •10 connections total The difference between Low Affinity and High Affinity connections are the activities that they manage. High Affinity requests will only be for Report Services and not Batch Services. Often times a High Affinity request is re-used such as a user viewing and html report and clicking the “page up/down” link or re-prompting. It is optimal to use an already established connection for faster performance. For more detailed breakdown of Affinity Requests the Cognos Installation Documentation can be referred to. Process Capacity Another method of streamlining performance is the setting for Processing Capacity also found in the Dispatcher Settings.  This setting is designed for unbalanced server(s) within a multi server installation. If Server A is twice as powerful as Server B the processing capacity setting can be adjusted to allow Server A more capacity. This setting can be beneficial when adding extra hardware to the existing environment to allow more throughput. Dispatcher Routing Routing reports to specific servers can be set up for various reasons. One potential performance impact is for long running reports that are run frequently. The dispatcher routing configuration can be found in the Dispatcher and Services section of the Administration Portal.  This configuration practice allows you to route a package to a specific dispatcher. In general one main goal of capacity planning is to not effect on demand behavior for users. By incorporating Dispatcher Routing, long running reports that are process intensive can be routed to dedicated dispatchers preventing latency to on demand users. So confused yet? The Cognos application has several configuration options available. Each customer’s demands will be unique. It is often thru trial and error that the most optimal configuration is achieved. This article was geared toward illustrating some simple changes that can be modified directly in the administration panel to achieve better performance. While there are several configurations that can be modified within the internal configurations of the tool the dispatcher settings in general are a logical place to start. Try only modifying one item at a time in small increments and document change over time in order to interpret best results. Article written by: By Chris Nakian, Consultant, BrightStar Partners.com |