Report in Designer fast, in Viewer extremely slow

Question

Hi.
I have a report which connects to a SQL Server backend, calling 3 stored procs which deliver the data needed for the report. However, when I execute the report in the Designer (the web app uses CR 9, but I'm testing it with CR 2008 that came with VS 2008) it takes approx. 20 seconds to return with the data - yes, the query takes rather long...
When I run our web application and call up the same report, using the same parameters and connected to the same database, the Viewer sits there for about 10 minutes before finally showing the report. I've been trying to determine the cause of this but have come up empty so far.
The report itself is a fairly simple report: headers, a parameter overview (the report uses parameterized queries), the data, and no subtotals, no subreports, no formulas.
Why is this taken so long using the Viewer? Apparently it can be fast(er) since the Designer comes within 20 secs WITH the correct data!
I've tried a couple of things to see if I could determine the cause of the bad performance, but so far I've had no luck in improving performance whatsoever. The only thing left would be redesigning the underlying stored proc, but this is a rather complex stored proc and rewriting it would be no small task.
Anybody has any idea on what to do next? Our customers are really annoyed by this (which I can understand) since they sometimes need to run this report a couple of times a day...

Answer 1

Ludek Uher wrote:>
>
> Troubleshooting slow performance
>
> First thing to do with slow reports would be consulting the article u201COptimizing Reports for the Webu201D. The article can be downloaded from this location:
>
> https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/701c069c-271f-2b10-c780-dacbd90b2dd8
>
Interesting article. Unfortunately, trying several of the suggestions made, it didn't improve the report's performance. No noticeable difference in either Designer or Viewer.
>
> Next, determine where is the performance hit coming from? With Crystal Reports, there are at least four places in your code where slow downs may occur. These are:
>
> Report load
> Connection to the data source
> Setting of parameters
> Actual report output, be it to a viewer, export or printer
>
This part is not relevant. Loading the report isn't the problem (first query being executed under 0.5 seconds after starting the report); as I'll explain further at the end of this reply.
> A number of report design issues, report options and old runtimes may affect report performance. Possible report design issues include:
>
> u2022 OLE object inserted into a report is not where the report expects it to be. If this is the case, the report will attempt to locate the object, consuming potentially large amounts of time.
The only OLE object is a picture with the company logo. It is visible in design time though, so I guess that means it is saved with the report?
> u2022 The subreport option "Re-import when opening" is enabled (right click the subreport(s), choose format subreport, look at the subreport tab). This is a time consuming process and should be used judiciously.
The report contains no subreports.
> u2022 Specific printer is set for the report and the printer does not exist. Try the "No printer" option (File | Page setup). Also, see the following resources regarding printers and Crystal reports;
Tried that. It was set to the Microsoft XPS Document writer, but checking the 'No printer' option only made a slight difference (roughly 0.4 seconds in Designer).
> u2022 The number of subreports the report contains and in which section the subreports are located will impact report performance. Minimize the number of subreports used, or avoid using subreports if possible. Subreports are reports within a report, and if there is a subreport in a detail section, the subreport will run as many time as there are records, leading to long report processing times. Incorrect use of subreports is often the biggest factor why a report takes a long time to preview.
As stated before, the report has no subreports.
> u2022 Use of "Page N of M", or "TotalPageCount". When the special field "Page N of M" or "TotalPageCount" is used on a report, it will have to generate each page of the report before it displays the first page. This will cause the report to take more time to display the first page of the report
The report DOES use the TotalPageCount and 'Page N of M' fields. But, since the report only consists of 3 pages, of which only 2 contain database-related (read further below) I think this would not be a problem.
> u2022 Remove unused tables, unused formulas and unused running totals from the report. Even if these objects are not used in a report, the report engine will attempt to evaluate the objects, thus affecting performance.
> u2022 Suppress unnecessary report sections. Even if a report section is not used, the report engine will attempt to evaluate the section, thus affecting performance.
> u2022 If summaries are used in the report, use conditional formulas instead of running totals when ever possible.
> u2022 Whenever possible, limit records through Record selection Formula, not suppression.
> u2022 Use SQL expressions to convert fields to be used in record selection instead of using formula functions. For example, if you need to concatenate 2 fields together, instead of doing it in a formula, you can create a SQL Expression Field. It will concatenate the fields on the database server, instead of doing in Crystal Reports. SQL Expression Fields are added to the SELECT clause of the SQL Query send to the database.
> u2022 Using one command table or Stored Procedure or a Table View as the datasource can be faster if you returns only the desired data set.
> u2022 Perform grouping on the database server. This applies if you only need to return the summary to your report but not the details. It will be faster as less data will be returned to the reports.
> u2022 Local client as well as server computer processor speed. Crystal Reports generates temp files in order to process the report. The temp files are used to further filter the data when necessary, as well as to group, sort, process formulas, and so on.
All of the above points become moot if you know the structure of the report:
3 pages, no subreports, 3 stored procs used, which each return a dataset.
- Page 1 is just a summary of the parameters used for the report. This page also includes the TotalPageCount  field;
- Page 2 uses 2 stored procs. The first one returns a dataset consisting of 1 row containing the headings for the columns of the data returned from stored proc 2. There will always be the same number of columns (only their heading will be different depending on the report), and the dataset is simply displayed as is.
- The data from stored proc 2 is also displayed on Page 2. The stored proc returns a matrix, always the same number of columns, which is displayed as is. All calculations, groupings, etc. are done on the SQL Server;
- Page 3 uses the third stored proc to display totals for the matrix from the previous page. This dataset too will always have the same number of columns, and all totaling is done on the database server. Just displaying the dataset as is.
That's it. All heavy processing is done on the server.
Because of the simplicity of the report I'm baffled as to why it would take so much more time when using the Viewer than from within the Designer.
> Report options that may also affect report performance:
>
> u2022 u201CVerify on First Refreshu201D option (File | Report Options). This option forces the report to verify that no structural changes were made to the database. There may be instance when this is necessary, but once again, the option should be used only if really needed. Often, disabling this option will improve report performance significantly.
> u2022 u201CVerify Stored Procedure on First Refreshu201D option (File | Report Options). Essentially the same function as above, however this option will only verify stored procedures.
Hm. Both options WERE selected, and deselecting them caused the report to run approx. 10 seconds slower (from the Designer)...
>
>
> If at all possible, use the latest runtime, be it with a custom application or the Crystal Reports Designer.
>
> u2022 The latest updates for the current versions of Crystal reports can be located on the SAP support download page:
>
> https://websmp130.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/bobj_download/main.htm
>
I've not done that (yet). Mainly because CR 10.5 came with VS2008, so it was easier to test to see if I can expect an improvement regarding my problem. Up till now, I see no improvement... ;-(
> u2022 Crystal Report version incompatibility with Microsoft Visual Studio .NET. For details of which version of Crystal Reports is supported in which version of VS .NET, see the following wiki:
>
> https://wiki.sdn.sap.com/wiki/display/BOBJ/CrystalReportsassemblyversionsandVisualStudio+.NET
>
>
According to that list I'm using a correct version with VS2008. I might consider upgrading it to CR 12, but I'm not sure what I would gain with that. Because I can't exactly determine the cause of the performance problems I can't tell whether upgrading would resolve the issue.
> Performance hit is on database connection / data retrieval
>
> Database fine tuning, which may include the installation of the latest Service Packs for your database must be considered. Other factors affecting data retrieval:
>
> u2022 Network traffic
> u2022 The number of records returned. If a SQL query returns a large number of records, it will take longer to format and display than if was returning a smaller data set. Ensure you only return the necessary data on the report, by creating a Record Selection Formula, or basing your report off a Stored Procedure, or a Command Object that only returns the desired data set.
The amount of network traffic is extremely minimal. Two datasets (sp 1 and 3) return only 1 row containing 13 columns. The sp 2 returns the same number of columns, and (in this clients case) a dataset of only 22 rows, mainly numeric data!
> u2022 The amount of time the database server takes to process the SQL query. Crystal Reports send the SQL query to the database, the database process it, and returns the data set to Crystal Reports.
Ah. Here we get interesting details. I have been monitoring the queries fired using SQL Profiler and found that:
- ALL queries are executed twice!
- The 'data' query (sp 2) which takes the largest amount of time is even executed 3 times.
For example, this is what SQL profiler shows (not the actual trace, but edited for clarity):
Query                  Start time         Duration (ms)
sp 1 (headers)      11:39:31.283     13
sp 2 (data)            11:39:31.330     23953
sp 3 (totals)          11:39.55.313     1313
sp 1 (headers)      11:39:56.720     16
sp 2 (data)            11:39:56.890     24156
sp 3 (totals)          11:40:21.063     1266
sp 2 (data)            11:40:22.487     24013
Note that in this case I didn't trace the queries for the Viewer, but I have done just that last week. For sp2 the values run up to 9462 seconds!!!
> u2022 Where is the Record Selection evaluated? Ensure your Record Selection Formula can be translated to SQL, so that the data can be filter down to the server. If a selection formula can not be translated into the correct SQL, the data filtering will be done on the local client computer which in most cases will be much slower. One way to check if a formula function is being translated into a SQL is to look at u201CShow SQL Queryu201D in the CR designer (Database -> Show SQL Query). Many Crystal Reports formula functions cannot be translated into SQL because there may not be a standard SQL for it. For example, control structure like IF THEN ELSE cannot be translated into SQL. It will always be evaluated on the client computer. For more information on IF THEN ELSE statements see note number 1214385 in the notes database:
>
> https://www.sdn.sap.com/irj/sdn/businessobjects-notes
>
Not applicable in this case I'm afraid. All the report does is fetch the datasets from the various stored procs and display them; no additional processing is taking place. Also, no records are selected as this is done using the parameters which are passed on to the stored procs.
> u2022 Link tables on indexed fields whenever possible. While linking on non indexed fields is possible, it is not recommended.
Although the stored procs might not be optimal, that is beside the point here. The point is that performance of a report when run from the Designer is acceptable (roughly 30 seconds for this report) but when viewing the same report from the Viewer the performance drops dramatically, into the range of 'becoming unusable'.
The report has its dataconnection set at runtime, but it is set to the same values it had at design-time (hence the same DB server). I'm running this report connected to a stand-alone SQL Server which is a copy of the production server of my client, I'm the only user of that server, meaning there are no external disturbing factors I have to deal with. And still I'm experiencing the same problems my client has.
I really need this problem solved. So far, I've not found a single thing to blame for the bad performance, except maybe that queries are executed multiple times by the CrystalReports engine. If it didn't do that, the time required to show the report would drop by approx. 60%.
...Charles...