SSRS Performance vs. SQL Performance; thousands of calls to CreateChunkSegment
Hi, all reports on our customers server are running very slow. Example: a simple, flat SSRS report takes 2 min. The same Sql statement, executed from Management Studio, takes 26 seconds. The Sql Server Process uses 700 MB, the SSRS Service process uses 3,6 GB. The report returns 700.000 rows. It uses a join from 5 tables, with 1,8 Mio and 0,7 Mio rows in the biggest tables. I observed that SSRS makes thousands of calls to CreateChunkSegment. Maybe this is an issue? See http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/ec6d2730-be50-4239-9063-7eb0b712ff48/ "select @@version" returns "Microsoft SQL Server 2008 R2 (RTM) - 10.50.1777.0 (X64) Apr 8 2011 14:16:38 Copyright (c) Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7600: )"
July 24th, 2011 11:00am

Hi Peter Schmeichel, In general, report processing time can be affected by report layout, paging, and complex expressions in areas of a report that have many instances. According to your description, your report takes too long to process may be caused by report layout or paging. Please refer to the following respects, and to check if those could help you to improve your report performance. 1. Expressions in the Page Header or Footer Force All Pages to Be Processed When you include a reference to the built-in field [&TotalPages], the report processor must paginate the entire report before it can render the first page. In addition, the report processor assumes that any complex expression in the page header or footer might contain a direct or indirect reference to [&TotalPages].To avoid having the report processor paginate a lengthy report, do not include a reference to [&TotalPages] or any complex expressions in the page header and page footer. 2. No Page Breaks in the Report As a user pages through a report, the report processor combines data and report layout information for each report page and passes the page to the report renderer. For a report that has no page breaks, the whole report must be processed before the user can view the first page. Add page breaks to report items to help organize the report into pages. This reduces the amount of data that must be processed for each page. 3. Processes Competing for the Same Memory on the Report Server Multiple applications that compete for the same memory resources on a report server can affect report processing. Please verify that the memory management configuration is the correct model for your report server use. Besides, you could consider creating execution snapshots or Caching Reports for the report. A report snapshot includes all report data retrieved for the datasets in the report definition. For more information, see Creating, Modifying, and Deleting Snapshots in Report History. Caching report could store the report layout and datasets returned from the database the first time the report is executed. For more information, see How to: Cache a Report (Report Manager) If the issue still exists, could you please check TimeDataRetrieval, TimeProcessing and TimeRendering in dbo.ExecutionLog2 table on reportserver, and to look for which spent the most time. And then, we could help you better. For more information about the topic, please see, Troubleshooting Reports: Report Performance: http://msdn.microsoft.com/en-us/library/bb522806.aspx ExecutionLog2 View - Analyzing and Optimizing Reports: http://blogs.msdn.com/b/robertbruckner/archive/2009/01/05/executionlog2-view.aspx If you have any question, please feel free to ask. Thanks, Eileen
Free Windows Admin Tool Kit Click here and download it now
July 24th, 2011 11:44am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics