Quick Tips to Improve Cognos BI 

Bursting Performance: 

Note: This is in no way an exhaustive guide to improve burst performance. 

It will allow users to deal only with the initial roadblocks. Advanced tuning 

will still need assistance from an IBM team. 

The below points are in no particular order but are a random list of possible 

issues. 

1. Break Larger Burst Jobs Into Smaller Ones: 

If you have a big set of users to burst to, it is advisable to break the burst into 

smaller parts. For example having one burst job bursting reports to 10K users will 

be highly inefficient as it will use only one process to generate the reports. It is 

better to break this into smaller jobs of say 1K users each so that the products 

scaling capabilities are used. 

This is better done using a parameterized filter rather than a simple filter since 

using the former will make the solution more maintainable. Using a simple filter 

will mean creating and maintaining n number of copies of the report and will lead 

to a maintenance nightmare. When a parameterized filter is used, n number of 

jobs can be created and they can be set to pass the appropriate parameter to the 

report. Agreed the jobs will have modifications too but the frequency of that act 

will be lesser than reports. 

2. Choice of Output Format: 

Though organizations can be pretty rigid on the output format, check if they are 

lenient to some extent. The common sense logic is that some output formats are 

costlier to generate than some others. Though this is not a big concern when 

generating a few reports, it becomes a significant factor when reports are 

bursted. 

3. File System Performance: 

If you are bursting to the file system, the performance of that system will affect 

the performance of your burst jobs. Though modern file systems give impressive 

performance, there could be problems like if you are using a shared file system – 

which is usually the case if you have multiple application tier machines. In case 

of shared file systems, the network could be a bottleneck. If it is indeed found to 

be so, try using a local file system and then pushing all outputs to a central 

location using a script. Even in case of local file systems, do remember that 

certain security policies may slow down the overall performance. 

4. Choice of Output Locations: 

If file system based bursting is being used, there are two distinct places where 

bursting can be done. The first one is the typical file system bursting where you 

define a file system root in Cognos Configuration and then have the report server 

burst the outputs to that location. 

The other less common way to burst is to do it on the Content Manager using the 

CM.OUTPUTLOCATION advanced setting. There are pros and cons to each 

approach. The report server bursting has been found to be typically slower than 

the CM bursting. The CM bursting on the other hand, stores outputs to the 

Content Store AND to the CM’s file system. This will load both the CM and the 

Content Store and these will need to be appropriately tuned. Another small 

hiccup with CM based bursting is that unlike the typical scenario, the output file 

names are not based on the burst key. There is another advanced setting to use 

the burst key but it will create directories with the burst key name and will place 

the output file inside each directory. This can be an inconvenience. A better 

option is to check the XML descriptor file that is generated along with each report 

output and to rename the output file accordingly. The CM method seems to be 

much faster than the typical file system bursting.

Heavy bursting using the CM method slows that service. Since there is no load 

balancing available for that service, it is recommended that the CM is monitored 

for load and burst jobs are scheduled appropriately. The recommendation is to 

run the burst jobs during off hours. It is also recommended to have a standby CM 

in case the active one goes down. 

5. Query Optimization: 

Bursting is a data intensive operation. Depending upon the report design, the 

load will either be handled by the database or Cognos BI itself. In some cases, 

the report design is based on a master-detail relationship which means a lot of 

database hits. It is imperative then that the query is optimized as best as 

possible. It is also recommended to use the single query format if possible. 

For a more detailed explanation on various report design options, please check 

this Proven Practice document: 

http://www.ibm.com/developerworks/data/library/cognos/page241.html 

6. Database Performance / Tuning: 

As mentioned in the above point, some report design choices will mean use of 

master-detail relationships. In such scenarios, the number of queries will be 

proportional to the number of burst keys. It is therefore advisable to tune the 

database to handle this volume of queries. The services of a database 

administrator (DBA) can be sought for this exercise. The database should be 

relatively free during the burst period or it should have enough resources to 

handle multiple tasks at the same time. 

7. Tuning Cognos Services: 

A burst job being a non-interactive report run, is handled by the Batch Report 

Service. When the monolithic burst report is broken into multiple parts, when run 

in parallel, each of these parts will need an instance of the Batch Report Service 

to run. Depending on the number of CPUs and available memory, the number of 

Batch Report Service processes can be increased. It is also recommended that 

low affinity connections are increased but be careful not to increase it to a very 

high number. Please refer to the Cognos Tuning Proven Practices to get an idea 

as to how this parameter should be manipulated for optimum performance. 

Apart from that, the Content Manager Service connections should be increased if 

the CM is being used to store report outputs. A slight increase in Delivery Service 

connections is also recommended. There is no objective recommendation for the 

number of connections. Typical performance engineering best practices should 

be applied. 

8. Approach: 

Like in all performance improvement projects, a disciplined and iterative 

approach is needed for this endeavor. It is recommended to change one 

parameter at a time. Also please do not the burst performance when each 

parameter is changed. If a complete burst run is not possible, please run only 

one part (refer [1] above). The Perf.QFS tracing can be used to check database 

latency or other issues in the data access stack. Ask your IBM engineer for 

procedures to do the Perf.QFS tracing.