RDLC export Excel - Slow

exporting a pdf and excel Takes way to long

Slow performance when exporting to Excel

The reports when run on their own is running fine and is loading within an ecceptable time. However, the problem comes when I start to choose to Export it to Excel.

The exporting process will take an exceptional long time to prompt user to save the Excel file and once it finishes downloading, it takes yet another exceptional long time to open up the Excel file. Can anything be done to rectify this slow Excel rendering issue

Another thing that I have realised is also this. If the amount of data that the report contains is not alot and the exported Excel file is around 2MB odd or less then that, it will not experience the slowness in the rendering process. However, if the data is alot and the Excel file exceeds 3MB, the entire performance slows down tremendously and sometimes even not responding when opening the Excel file. It is the normal behaviour

------------------

If your report contains paging, RS can return the first page of your report while processing the rendering of the rest of the report in the background and hence the perceived good response from the web report.

When exporting there are various aspects that could affect the perceived response time:

• Firstly the report has to perform all the rendering and not just the first page
• bigger volumes mean more renderign time and a bigger file to download
• the speed of the network connection (bandwidth) between the client and the web server will affect how quickly the file downloads and when you see the save dialog
• the hardware of the workstation e.g. processor, memory, virtual memory, disk fragmentation etc. could all affect the time it takes to open a big excel file.

http://www.windows-tech.info/15/700b86b7e7750bf9.php

 

Once again, my real question is why does exporting a 20 MB file to excel
chew up more then 1.4 GB of virtual memory?
Based on the previous responses to this thread, I am sure you can reproduce
this issue yourself. This must be a known issue in the Support DB is it not?
My primary concern is not that I can't get my data out of Reporting Server,
but that I have a production report out there with an export option that
will sink our reporting server and mess up the reporting experience for our
other users.
Is there a way to either fix this issue or turn off the excel and pdf export
options for specific reports?
For now all I can do is instruct them to not to use that option on large
data sets.
Sorry to be blunt, but this does not present a professional or bullet proof
solution to my clients deserve.

 

http://dbaspot.com/forums/ms-sqlserver/232374-re-export-reporting-services-slow.html

 

All rendering is done in RAM. The working space necessary will depend on the
complexity of the report. You could try a test where you simplify the report
as much as possible and see if that helps. One thing I have done in the past
is have a report just for export. I provided a link at the top of the report
and used Jump to URL to render the report. I would removed grouping,
subtotals, etc etc. Then in report manager I would hide in list view so the
user didn't see the report. Another option for you to try.

http://www.eggheadcafe.com/software/aspnet/30353388/i-am-having-same-problem.aspx

 

I see the same issue. I tuned the query to produce 56,000 rows in < 20 seconds.

The report renders in less then 40 seconds as well.

I put Task Manager server on and see virtual memeory creep up over 1.4 GB

before it hits the cap I had set. When it hits the cap on virtual memeory,

the CPU spins at 100%. This report contains about 10 MB of data so it should

not need 1 GB of memory to run.

 

In SQL Server Reporting Services 2008 the excel renderer is rewritten and there are many performance and scalability improvements done for it. However the scalability and performance of excel renderer  in 2008 still depend on the size and complexity of the reports.

http://social.msdn.microsoft.com/forums/en-US/sqlreportingservices/thread/81d1fac6-bd16-43f6-8e02-1d1571693c86/

 

http://www.bigresource.com/Tracker/Track-ms_sql-dAVQKX1Q/