Hi there, I have a report that shows minutely data on a chart. as the report is usually shows a week long time period it has quite alot of data points (i.e. 10080). The problem is that report rendering takes lots of time - around 4 minutes (or more)! I can't use report cache as the report has some parameters the users neet to change, and the time period is unknown. I've checked, and the data set takes no time at all to load. the delay is in the rendering. Any ideas on how to? Should this take so much time? Thanks!

Hi Meizu2, Report rendering occurs after data and layout are combined into an interim format and then passed to a rendering extension. Rendering time can be affected by the amount of data, the number of instances of report items, and paging. When you export a report, you are passing the interim format to a specific renderer. If you know that the users view a report in a specific format, you must optimize the report for that renderer. For more information, see Exporting Reports and Understanding Rendering Behaviors. Use this section to help improve rendering performance for a report. Report is Not Optimized for the Chosen Rendering Format Some features are not supported in all renderers. If the primary format for viewing a report is a specific file format, you might have to modify the report design to optimize the viewing experience for the user. Add page breaks where it makes sense. For example, each page break defines a new sheet in Excel. Each sheet can handle a maximum of 65000 rows. Consider these limits when you set the page breaks in a report. For exporting to Excel, do not merge cells in a Tablix data region. In free form reports, align report items vertically. Merged cells and unaligned report items interfere with Excel functionality in the exported report. HTML parsers are not efficient at rendering very large HTML pages. If you have trouble rendering a report, select a format that produces a smaller file (for example, CSV). If you cannot select another format because the report toolbar is not available, you can define a subscription to set a rendering format and deliver the report as a static document to a file share. For more information, see File Share Delivery in Reporting Services. Thanks, Lola Please remember to mark the replies as answers if they help.

First of all, thanks for the reply. However, this doesn't solve my problem. The report is vied from the report server report viewer and not rendered in any special format. There is no paging, no tables, no pictures - only a single chart. CSV isn't an option as the idea of the report is to show a graph and not raw-data. Since the report has some parameters that the users need to select, Excel rendering will only be possible if I'll write a website to encapsulate the parameter selection, and make it referance the url with those parameters and the render extension - this isn't a prefered solution. The parameters also prevent sbuscriptions from being a solution. Thanks.

Greetings Meizu2, Whilest its not the technical approach towards your problem and it will reduce the complexity of your rendering: As 10.080 points for 1 week time seems quite a lot; did you try to lower the precession of the report? I can envision that making a simpeler 'week-chart' that shows the trend is nearly 80% of the requirement. Add a detailed sub-chart, which lays out the points per day to meet the other 20%? with kind regards, Sebastian

Thanks Sebastian. We're actually implementing this solution, as there is a report that shows hourly min and max data. However, as you've mentioned, this isn't a full solution, and the users quite often need to look at a weekly minutely data. When they do, they change to look at serveral combinations of parameters, so a run time of 5 minuted every time is annoying.

Btw, Meizu There is a known issue about Report-viewer and visual-heavy reports because of the call-backs between sharepoint and reportingservices. Someone made a awesom report on it, unfortunatly i dont have the link anywhere near me. So you can try running it in Native-mode to speed it up. Secondly and maybe more inportant: i was informed today that the 2012-addon also functions on an SQL 2008 R2 database. If you travel this route, can you keep me posted on your findings? As i have yet to implement that part but it might be a venue to resolve your issue. "Microsoft SQL Server 2012 Reporting Services Add-in for Microsoft SharePoint Technologies 2010" ~ http://www.microsoft.com/en-us/download/details.aspx?id=29068 with kind regards, Sebastian