It's all about the answers!

Ask a question

Performance Expectation of Report->Export->PDF

Scott Sherwood (5624) | asked Mar 28 '13, 3:48 p.m.
We have a large Rational, multi-vendor solution centered around 3.0.1 RTC.   The vendors using Rational include IBM as well as competitors and our primary client.  In total, 1000 users but with a high variability in their usage and needs.  One common element is that prior to buying and installing RTC, the client had the vendors all generate Microsoft Excel and Powerpoint standard reports to convey a project's status.  We now track all of that data in RTC - milestones, issues, risks, for example, and we can generate the same visual reports in RTC Reporting.  While this is sufficient for real time usage, the client has many stakeholders in the project who want to look at historic reports, or want a common version of the data on a report sent to many users who won't have access to RTC.  We are trying the Export PDF option for the rendered reports, but we have some users who are experiencing very long processing times for the conversion.  It is longer to convert the report to PDF than to generate the report, and the report takes 3-5 minutes many times. 
  1. We see opportunities to improve the report generation, but are there any options to improve the export/conversion to PDF? 
  2. What performance should we expect before we raise a PMR? 
  3. Frankly, I have advised some users to install CutePDF and print to that.  Are there any other suggestions?

Krzysztof Kaźmierczyk commented Apr 02 '13, 2:57 a.m.

Hello Scott,
CLM uses BIRT to export reports to pdf. This framework is mainly developed by Acutate which is not part of IBM. Anyway we will try to help you.

As reports differ between each other, it is really hard to say what is expected performance. Please notice, that it depends on many factors eg. number of work items/attributes in your RTC, report parameters set, report size etc.

In order to investigate this issue we need a bit more data regarding your issue.
1. What is the time of generating report for your "fake" reports? How much it differs from exporting report?
2. Which reports do have the issue? Do you set any specific parameters for that reports? Or it happens for all parameters for given report?
3. Has the issue appear immediately after installation?
4. Does it happen for all users?
5. You mentioned that you are generating also powerpoint reports. Do you observe also performance degradation for pdf reports?

I did not find any additional hidden features of reporting.
As another work around, you might consider using RRDI/Insight or RPT for report generation (at least temporarly)

Scott Sherwood commented Apr 17 '13, 1:38 p.m.

Hi Krysztof,
1. It takes anywhere from a minute to 5 minutes to "generate" the reports.  I say generate in quotes because I am not certain how much of the time is being spent in queries and joins, in filtering, in calculating, in rendering, etc.  I have read the information on the metronome tool, but when we tried this we couldn't trace the report activity very well.
2. The reports all have '{current project area]', then we get a single team area, iteration and category.  We only use the iteration and category in the queries.
3. The system has been running for about a year in various training and pilot capacities.
4.  The performance is poor for all users, but we do know there is a network issue with a set of users.  We have a fairly complex network environment that the client demands we run on.
5. I separate the poor performance into 2 areas.  1, it takes "minutes" vs. "seconds" to run a report, and 2. it takes minutes vs. seconds to Export the report, regardless of the format.

One answer

permanent link
Scott Sherwood (5624) | answered Apr 17 '13, 1:39 p.m.
As you might imagine, when these things happen the support teams run around on fire and do lots of actions on the servers, networks, etc.  The performance is still slow from a user perspective, i.e. 3-5 minutes for the main report which presents in total about 400 attribute instances from about 20 work item instances over 3-4 types.  But, roughly 75% of those attributes are custom which had us down a join path.  We are looking at a calculated path where we create a "get" query if you will and fill up arrays with the custom attributes.  Then we place them all in a single table using calculated values.  We have one report that uses this technique and it seems to run OK.  i.e. < 1 min.  So, we are not certain if it is joins, or nested tables, or calculated values or what "internal" parameters drive the performance of either BIRT or the Exports.   We are learning like everyone else, I think.  :-)

I'll post any updates here for folks.

Your answer

Register or to post your answer.