I have created a report with Report Builder 3.0
I'm running it on Microsoft Reporting services 2012
When O look in the performance logs (via ExecutionLog3) I see that all 3 phases(Retrieval, Processing, Rendering) took about 2 secs. But the browser take 7+ sec to present it (and it is consistent that there is 5-10 seconds overhead), what might be the source of it?
Could be one of two things most commonly:
The problem MAY BE, not sure, that your SSRS server is recycling every 12 hours and the first report of the day may be accessing the catalog on the ReportServer, getting the site up and running and then giving you a report. Generally this is common with SSRS and sometimes may take up to a minute for the first report of the day. Generally you can create a 'keep alive' service to poke SSRS every few hours at http:// (servername)/ReportServer which is SSRS's web service. You can also I have read set a config setting on the SSRS server itself but that never worked for me so I gave up and created a keep alive service instead.
The report can be taking a long time if a developer created a lot of functions on top of the data to render it with font changes, size changes, color changes, dynamic logic. You mentioned 'Rendering' in the time you looked up but if the report is not rendering in the browser how are you seeing rendering happen faster?
Generally it is both of these things in different situations. Best way to check 2 is create a super simple report with no parameters and a simple dataset that returns a black and white grid.
Related
When developing my report in BIDS, the Go to Bookmark action is pretty quick but after deploying my report to the server any bookmark click takes about 10 seconds with the "Loading" pop-up. My report is 1 (potentially long) page but it displays a lot of information so i wanted to be able to add a little index at the top. I've tried DocumentMapLabel as well but it's the same loading issue but I have no control over how gargantuan the side bar is for the tiny tree map it displays.
My query runs in less than a second so pretty much all of the time waiting is on SSRS.
Any ideas what is going on or if there are setting i can change to make it more snappy?
thanks.
well, i work remotely so i'm not on the network that the report server is on directly. After remoting into a machine that is, the bookmark feature is nearly instantaneous. I'm not sure why it matters for this feature but I suppose i'll be testing my report on the remote machine instead.
I have a stepped report that has 5 row groups. Each one uses an expression as the value to group on. The user selects a value for up to 5 different parameters and based on those parameters is how the report is grouped.
With certain combinations of parameters the report may take 2min + to run in the preview pane in Visual Studio. When I deploy the report to the SSRS server the same combinations of parameters runs in 10 seconds or less. Out of curiosity, I created a copy of the report and removed the expressions from each of the row groups and specified a field to group on. In that case it previews just as fast as when viewed on the server.
Anyone have any idea what may be going on here?
I'm currently using Visual Studio Enterprise Update 3.
I realize this is an older issue, but maybe this will be some help to you.
I am experiencing similar symptoms to what you have described and it comes down to using dynamic fields in grouping statements. Apparently, any other statement can use dynamic fields without issue, but groupings incur a huge performance hit.
This link outlines the symptoms and causes.
I don't know if it was in that particular link or not but I read something about how the ReportViewer control when it renders to HTML has a bug in it that only happens when the control is running under .Net 4.0 or higher. In .Net 3.5 the performance is pretty much the same as it is if you were to run the RDL in the Report Viewer application.
If you are able to do so, the quickest way to get the report viewer component to work is to have the application pool IIS is using to run under .Net 2.0 (or 3.5 if that option is there, since they're basically the same thing).
If your application uses .Net 4.0 or higher for other functionality, there isn't much I've been able to figure out, short of rewriting the report to remove dynamic references from groupings, but that significantly reduces the interactivity of the report (no expand/collapse options in table rows/columns).
For reference, I had a report, where the query took about 2 minutes to execute, and then rendered almost instantly afterwards if I loaded the RDL in SSRS. That same report rendered using the ReportViewer control in .Net 2.0 took about 2 min 30 sec to fully render. Using the exact same code, but changing the app pool to use .Net 4.0, the report has been "rendering" for roughly 15 minutes now and still hasn't come back.
First of all and a bit obvious, if you are running your report in a development machine it won't have the same computing power as a server. Even if you are running VS from the server it won't run as fast as a deployed report.
The cause -as you may notice- for the slow performance is the grouping expression. It seems your report is taking to long to process so check this article from a Technet post. I copied and pasted a paragraph below:
Many levels of nested and adjacent groups in a Tablix data region can
affect report processing performance. Consider both the level of
grouping, the number of group instances, and the use of aggregate
functions which require evaluating after group, filter, and sort
expressions are applied.
I recommend you try to perform the grouping in the datasource at SQL level, you can also pass parameters to the query to set the desired grouping there.
Let me know if this helps.
Background:
We recently migrated to SSRS 2014; our source database is SQL Server 2008 R2. We ran into some performance problems on a report where it simply would stop responding and ultimately timeout after 30 minutes when rendering the report. Reviewing the execution log on the reporting server indicates that the data retrieval time is low, while the report rendering time is high. The solution our DBA discovered after a month of this problem, is to set READ_COMMITTED_SNAPSHOT ON.
This seems to have cleared up the very strange performance problem with a single report. This report would seemingly become deadlocked when users attempted to generate it. The deadlock appears to be on the temp report server database, occurs only when returning the report to the browser (IE or Chrome), and does not occur every time the report is generated, but may be occurring when multiple users are attempting to generate the report around the same time frame. The report has 3 levels of grouping, and returns a variable amount of rows for the entered parameters.
This setting (READ_COMMITTED_SNAPSHOT) seems to now have caused a secondary problem: in the navigation bar of the report, where the user can navigate through the pages on the report, initially displays 0 of 0 when an active "Next page" button. When the user clicks the "Next page" button, the browser performs a post-back (like it would if you were navigating to the next page) and refreshes the screen with the first page. Now, the navigation bar displays 1 of X.
All of our SSRS servers received READ_COMMITTED_SNAPSHOT ON, so I had asked the DBA to update my DEV server to OFF. When this was done, I re-generated all of the reports (about one dozen), and each of them initially displayed 1 of X pages, as I would have expected. Now, I question whether setting this property to ON was the correct approach for fixing the report.
I thought about whether creating a report snapshot would be a good solution, unfortunately, I don't think it is as we have users which have differing parameter selection.
Questions:
Was there a better way we should have solved the report performance problem above rather than setting READ_COMMITTED_SNAPSHOT to on?
Does READ_COMMITTED_SNAPSHOT and ALLOW_SNAPSHOT_ISOLATION need to both be set to true/on if one is?
Has anyone encountered this problem related to the Navigation Bar in SSRS, and how were they able to resolve the issue?
Update:
We ultimately had to roll-back the READ_COMMITTED_SNAPSHOT setting, as it caused an entirely different error to occur. The problem outlined above, also seemed to clear itself up, with no issues reported two months in a row. Unfortunately, no one knows what was causing the issue in the first place, or what may have fixed it (possibly a hardware change).
I'm assuming you changed these settings on the source database of the reports, not the SSRS server itself (unless they are the same server). Changing the settings of READ_COMMITTED_SNAPSHOT and ALLOW_SNAPSHOT_ISOLATION can have wide-ranging effects on your systems, so should be done with caution. See https://dba.stackexchange.com/questions/5014/what-risks-are-there-if-we-enable-read-committed-snapshot-in-sql-server for potential issues related to changing these settings (and also an answer to your second question).
To me it sounds like the problem is in your report query or queries, so changing these database level settings to resolve a performance problem in one report is probably overkill. I would first look at analysing your report queries and tuning them (and possibly adding missing statistics or indexes to the source database) before altering row versioning settings.
As to the navigation bar issue, perhaps the changes made to the row versioning mean the SSRS is unable to calculate the number of pages available when the page is initially loaded. However I don't know why that might happen.
I have SQL Server 2008 R2 with SSRS. I have created an SSRS report that may contain up to 3,000,000 rows.
When I tried to generate such huge report I saw the following picture:
The stored procedure (one that brings the data into the Report) worked 50 seconds
After this the SSRS ReportingServivesService.exe started to consume a lot of memory. It's Working Set grew up to 11 GB. It took 6 minutes; and then the report generation failed with the following error message:
An error has occurred during report processing. (rsProcessingAborted)
There is not enough space on the disk.
“There is not enough space on the disk.” – this was probably about the disk drive on that server where the Windows page file was mapped into. The drive had 14 GB of free space.
A NOTE: the report was not designed as a single-page report. It is divided on pages by 40 rows. When I try to generate the same report with 10,000 rows – it takes just 1 minute.
The question is: can this be fixed somehow?
SSRS is extremely ill-suited for this kind of scenario. Tools like BCP or SSIS seem much more suited to this task. The question you ask ("can my situation be fixed") is not quite answerable, apart from being answerable by you by demonstrating that it can be done.
In my experience though, I wouldn't think of trying to get 3 million rows to work in SSRS.
If you insist or are compelled to try anyways, here's a few things you can do to improve the situation:
Dive in to the rdl and remove everything you don't need: font instructions, dimensions, images, etc. Check regularly in the designer if the file is still valid. You could even consider rebuilding the report with as little extra features as possible.
Move any expression or dynamic ssrs bit to the query.
Remove all formatting and formats for cells.
Increase disk en memory space. If you are compelled to generate such big reports in SSRS you're gonna need it. Close any other application you can, your PC or Server's gonna need all the resources it can get for this. Normally I'd consider this a non option / as an indication you need different tooling though. But I'm beginning to sound like a broken record :)
Choose the export format wisely. Excel or PDF is gonna take many additional resources, e.g. CSV renderer will be much friendlier.
I am using Dynamics CRM 2013 on premise.
I have built all the reports based on stored procedures in SSRS.
one report however, that has no issue with execution definitions, permissions or what ever,
once executed causes to browser to crash (any browser, i tried FF, Chrome, IE9 and up, )
it seems the problem is not a report execution problem but a report rendering problem for this specific report.
I cannot cache the report or make a snapshot of it, as the values of the reports also depends on the user running the report (among other parameters user-defined) and each user should get a different result. - i have more than 400 users.
I have tried searching for any one who had face this kind of issue and reported on it but failed. hence decided to post this question my self.
if anyone has any idea, please share.
thanks
Have you enabled tracing/logging in SSRS? http://msdn.microsoft.com/en-us/library/ms156500.aspx
You might turn on verbose logging while trying to run the report to see if you can get more helpful information.
If you write code, you can write a .NET application that calls the SSRS web services to render the report. Doing that will help you know for certain whether it's a browser rendering issue since you can get back the report as a byte array and save it to disk as Word, PDF, etc.