- The load on the server
- The amount of data you need to consume
- The expectations of your user
- The “freshness” of the data required
- The bandwidth requirements of large amounts of data
There is no one-size-fits-all technique, as different scenarios require different approaches. For example, a user of an Excel integration who expects to import 25000 rows of data into a spreadsheet has a different expectation than a user in a CRM system who hovers over an item and expects a pie chart from Cognos to appear in a pop-up window. Both users want their application to be high performing, but the Excel user values the volume of data over instant responses.
With CMS 10.1, there are several new options to help apply the best technique to the application at hand:
- Caching of report runs allows you to ask for the report again without rerunning
- Interactive pagedReportData mode runs reports page-by-page for faster response times when building interactive applications
- Dataset/DataSetAtom XML formats provide a concise data-only format for dealing with large volumes
- Selection query optimization speeds report runs by only running the query for the report part selected
These features can be combined with existing features from previous versions of CMS:
- Using saved report runs reduces load on the server
- Synchronous report runs shortens overhead time
- Releasing sessions frees up resources on the server to handle larger request volumes
Caching of report runs
CMS now automatically caches report runs. This allows you to ask for the report again without hitting the database. For example, in REST you can now do this
- Run a report in LDX
- On the session URL returned (i.e. http://localhost/cognos/cgi-bin/cognos.cgi/rds/sessionOutput/conversationID/i123467) you can append ?fmt=HTML to get the HTML output from CMS without running the report again
Due to the structured nature of SOAP, you can not change the format of the cached output. However, you can reuse the same session information to form the REST URL to retrieve alternate output formats without rerunning the report.
Interactive PagedReportData requests
Previous versions of CMS returned the entire report in a single request. This technique is generally preferable for data mashups such as alternate visualizations where all the data is required to represent a true picture. However, for many integration scenarios a more Viewer-like experience with quick response times is required. With CMS 10.1 you now have the option of running report using the “pagedReportData” request. In this mode, CMS will return output a page at a time, and like viewer you can move back and forth through the document and perform drill up/down/through while still having access to all the regular CMS features such as the various output formats and report part selection.
LDX contains all
of the data and formatting for a report, which makes it a very rich
but very verbose output. For data mashup scenearios, CMS has
introduced two new output formats called DataSet and DataSetAtom (not
to be confused with the XML output generated by Report Server). These
two formats return just the raw values for lists, crosstabs, and
charts which makes it easy to perform data mashups without parsing a
large XML document.
<?xml version="1.0" encoding="UTF-8"?>
Selection Filter Query Optimization
When selecting a single report part, CMS now optimizes the query so that additional queries that are not part of the selection are excluded, resulting in a significant performance gain for multi-query reports.
Saved report runs
With “enable enhanced features” on the report properties turned on, you can get enormous performance gains by scheduling report runs during periods of low activity and using the saved output instead for your mashup.
Synchronous Report Runs
By default, CMS will run reports in asynchronous mode that provides allowances for long running reports and secondary operations such as drilling and paging. However, if you know that you will not need to make any secondary requests, you can specify that the report runs synchronously in REST. This removes a small bit of overhead required to create a session to manage the report's lifecycle.
If you know that you are not going to make any additional requests to the report and are running the report asynchronously, you should release the report session using the release command. This frees up resources on the server and allows a higher volume of requests to be processed.
Performance is one of the most challenging considerations any application developer faces. The new features in 10.1 will help make your life as a CMS developer easier in tackling it.