I’m working on a custom style of the ARForm report (AR Invoice), and it takes over 10 minutes to run.
I opened the report with SSRS Report Builder to see if I can figure out what is going on.
But when I click Run, it takes a good 30 seconds before the parameters pane (where you enter the TableGuid) to appear. This makes me think something is messed up in the RDL itself. If it was the RDD alone, I’d expect the TableGuid field to appear instantly, and the processing (after entering the tableGuid) to take a while.
I would start with following the query in this post by @josecgomez. I would also check your report server log files and look for error around the time this report is executed.
I have found a lot of report speed issues are resolved with this as well.
Was this the data retrieval time? You could start by just restarting your SSRS service and see if that helps.I assume things like disk space, free memory, and CPU utilization all look good?
Are your standard reports running fine? Did you review your SQL Reporting services log?
I have seen the SQL Update (link in original response) fix several custom report performance issues. To make sure this is part of the problem you can review your Reporting Services log on the SQL Server. The default path to this file is %programfiles%\Microsoft SQL Server<SQL Server Instance>\Reporting Services\LogFiles. Depending on how your SQL server reporting services were installed this could be quite a bit different. You can look at the reporting service to find this easily.
The knowledge base article typically addresses the TimeProcessing so while I would recommend applying the update, if you can, I would not bet on that fixing the issue. I guess I would restart SQL Server Reporting Services and see if you gain any performance uptick with this report. You could also take the SQL query text from the RDL and run it against your Epicor Reporting Services database to see if that is fast.This could be tough if you have sub-reports and/or multiple datasets. SQL Profiler would be the next step if you cannot narrow it down with the above attempts. You could run a duration trace just to see where the long execution time is coming from. It could be that your Epicor Reporting Database has thousands of rows coming across and populating it. You could directly query a couple of the tables, in your Epicor Reporting Database, once the data has generated to see if perhaps something is causing a higher than expected number of rows to come over.
Yep, that shows the aggregate rows, which could be a pretty good indicator of a problem. I would check the tables if that number seems too high to see where the problem could reside. You can look at the additional info column as well in the ExecutionLog3 table for individual row counts.
Check the timeouts, document you can find in the epicweb.
We tune the network. Check the TTLs between servers.
Maintenance of the database logs.
But what seemed to work was the tuning of infrastructure. The Inventory / Reconciliation Report was a torture, took about 12 hours or more. And now no more than 20 min.
We re-indexed the Epicor Database only… There was one report it took like 3-5min to run… despite restarting servers… doing a basic full database re-index solved our issue.
At my current company, I inherited a system where there was no routine maintenance on the DB indexes for Epicor – the system got slower and slower on certain reports, until I realised that the indexes were needing re-index. I now have a weekly scheduled job on the SQL server that does a full index rebuild and update statistics.