IBM Cognos Analytics 11 –

Performance Tuning

Cognos Report Studio Performance

Tuning
Prompt Page:

We have to ensure that the parameter definition matches the parameter usage.
Parameters are defined in filters and calculations. The resulting parameters are used in
prompts.

Some prompts don’t handle large volumes of data well. For example, a value prompt
that picks 100000 entries will be slow and unusable. For this type of scenario we can
use Select and Search Prompts, Cascading prompts.

We can use a Select and Search prompt instead of a Value Prompt if the list of values
are very long. A long value list could be the reason for slow performance.

Also if we have the option of choosing Product Code and Product Type to use as a
prompt, always choose ‘use value’ because a Product Code is always better option to
improve performance.

Performance Affected due to heavy usage of Fonts:

We can avoid usage of heavy fonts. Always use fonts like Arial.

Filters:

We can always use a date filter from the Fact table to improve the performance. Hence
it will directly hit the partition.

Page | 1
Complex Calculations and Filters always use in Frame Work Manager to improve report
performance.

Avoid Summary filters & instead use detail filter with after auto aggregation ,summary
filters are processed at Cognos server which hampers report performance.

Various Options in the query properties for improving query performance:

Database only, Limited Local

Specifies whether the query engine will pick up a minimal amount of processing. Local
Processing will only occur if the database cannot handle the load.

Maximum Tables:

Specifies the maximum the number of tables that the query can retrieve. If the value 0 is
specified, no error is returned and there is no restriction on the number of tables that
can be queried.

Maximum Rows Retrieved:

Specifies the maximum number of database rows the query can retrieve. An error
occurrs if the number of database rows returned exceeds the specified values.

Use Local Cache:

IF set to Yes, the query engine can reuse existing SQL results. IF set to No, the cached
results will not be used. The query will be executed. Improve performance by reusing
cache data when running a report.

Execution Method:

Specifies whether the query is allowed to run concurrently or sequentially. Concurrent

Query execution can improve performance in some cases.

Use for Parameter Info:

Page | 2
Prompt Query with this property set to Yes will always check parameter information first.
Setting this property to Yes on parameterized queries can improve performance in
displaying prompt pages.

Output format

The process Cognos follows in generating report output depends in part on the output
format being used. With an HTML report Cognos will fetch the data required to display
the first page of the report in the browser window. When the user clicks on Page Down
it will query more data and generate the next page. With file based formats like PDF and
Excel Cognos must fetch all the data and build the entire output file before anything can
be presented to the user. In some case this creates the appearance that the report runs
much faster when it is run to HTML.

To get a better idea of the time required for a report when run to HTML, run the report to
HTML in the background and save the output to the content store, then check the run
history to establish how long it takes. There will likely still be a difference between
running the same report to HTML and to other formats. If the report is displaying a large
result set the difference could be significant. This is due in part to inherent differences
between the different formats.

Outer joins

Outer joins and cross products can arise either from the model or from the report
design. In either case then tend to cause poor performance and should be avoided.

Use SQL with clause

The “Use SQL with clause” property for a report level query should be set to ‘No’ ,as it
fires multiple queries on database.

Page | 3
Framework Manager Performance
Tuning
Indexing – creating proper indexing will help FM traverse your data source more
efficiently. Although FM can use a database that is not indexed, it will impact
performance as the database grows.

Normalization – Framework Manager can work with different data structures, but works
best when the sources are normalized. Don’t worry about trying to achieve the highest
form of normalization – 3rd to 4th will do the trick.

Star Schema – Using a star schema will ensure FM creates the most efficient database
request. In the rare case, you can also use a Snowflake Schema and still achieve good
results.

Consolidate – If you have to put together multiple tables in order derive a single value,
you might consider doing such work in the database and then present the results in a
table for FM. Framework Manager can join multiple tables, however, the more layers
you build the longer it takes to return a value. Performance is further compounded by
the amount of data that must be returned.

Required Elements Only – When building FM only, bring in the elements you are
going to use. If you have fields in a view that are not used in the report request, FM will
still build the query command with all the fields in the view.

Additional things to improve the Performance At Framework Manager level

 Use Governor setting to restrict tables,query execution time limit etc.

 Avoid cross joins or Cartesian product & outer joins between the tables .
 Use model based Query Subject over Data source query subject.
 Minimize package content by creating model based query subject.
 Use proper proper usage property for query items like Fact for Aggregate &
numeric columns.
 Use correct cardinality.
 Use determinants cleverly to improve performance.

Page | 4