r1 - 2016-06-03 - 15:37:47 - TimFeeneyYou are here: TWiki >  Deployment Web > DeploymentPlanningAndDesign > CLMUsageModelBestPractices > JRSReportBuilderBestPractices

Report Builder Best Practices

Authors: KevinCornell, ErnestMah, TimFeeney
Build basis: The Rational solution for Collaborative Lifecycle Management (CLM) and the Rational solution for systems and software engineering (SSE) v6.0.1.

Scope your reports to include only the data required by the report consumers. Reports that include more results or attributes take longer to process and render.

Narrow the result set as early as possible in the query processing. Retrieving large amounts of data, then applying filters or joins, can increase the run time and the memory demands. Optimize and tailor the queries you run most often. If you require reports that return a large number of results, run them during off-hours or when server usage is light.

Widgets with multiple pages of results place additional demand on the server, while dashboard users are unlikely to click through all of those results. Ensure your dashboard widgets provide a relatively small result set. For dashboards with high or frequent use, avoid including widgets returning a large number of results; alternatively, put them on low use tabs.

Data aggregation reports and some time series or trend reports can take longer to run, depending on the amount of historical data in the data source. Using larger time intervals increases the load on the server, although repository size can also be a factor. Limit the time interval for trend reports, and ensure you test the performance in a “worst-case scenario”.

When users create reports (and Report Builder generates the SPARQL), Report Builder attempts to optimize the generated query based on the selected types used in the report and the complexity of the filters. However, a user can still generate long running reports.

Tips on Report Builder (RB) queries/filters:

  • Use project scoping or filters to limit amount of data returned. For example writing a report to trace all work items to test cases to requirements will take a long time if the user does not use project scoping or does not define any filters (such as work item type).
  • Traceability reports that use optional instead of required relationships will take substantially longer to run.
  • In addition, if the reports do sorting on a column, the generated query uses the ORDER BY statement. If there are a lot of resources to consider in the query (e.g., more than the maximum number of allowed results), the query engine in LQE has to get all of the possible results, sort them and then apply the limit restriction. Thus sorting in queries can take substantial time.

Related topics: Best Practices for CLM Usage Models

Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r1 | More topic actions
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use. Please read the following disclaimer.
Ideas, requests, problems regarding the Deployment wiki? Create a new task in the RTC Deployment wiki project