Why do reports take longer to run in 3.1 than they did in 10.3?
Problem
Reports seem to take a lot longer to run in 3.1 than in 10.3. Why is this?
Solution
There are many factors in play in 3.1 with regard to running a report, but these three (3) items in sequence are big contributors:
1. All reports run on the AppServer. This means every running of a report causes the creation of a 'Run Now' Scheduled Event. That event has to get picked up and queued by the Event Timer, and then the event has to run. In our experience, it is not uncommon for there to be a delay of up to 20 seconds from the time the user clicks Process to the time the report gets queued to the Event Timer.
2. Once the Report is queued to the Event Time, it has to be run by an AppServer agent. At this point, you get into the dynamic reporting overhead. This is the process of the system matching all the report criteria. Depending on the scope of your report, this may require a number of passes through various data tables in the system in order to gather results.
3. After the report completes, it is put into the Notification queue. Again the Event Timer has to run to pick up the 'Complete' notification and display it. Depending on your Notification settings, this could take an additional 5-20 seconds.
Review Your Log Files
When you run a dynamic report, the system writes a message to the log file upon completion to show how long the dynamic report logic actually took.
Assuming your AppServer logging is set to a minimum of Errors and Information, the message will look something like the example below with your report name listed. This total does NOT include the time it took for the report to get queued and run by the AppServer nor the time it took for the Notification checker to pick up the completed report. It includes only the time it took the system to actually run the dynamic reporting logic and filter the results.
The message will give the Overall Time (Start to Finish of the Report Logic), Screen Read Time (The time it took to convert your selection criteria into a valid query on the back end), Fetch Time (The amount of time it took to query all of the data for the report), and PDF Creation Time (The amount of time it took to generate the PDF once all of the data was gathered).
SAMPLE EVENT.LIVE.SERVER.LOG MESSAGE
[Your Report Name Here] Overall Time/Screen Read Time/Fetch Time/PDF Creation Time (Seconds): 51 / 8 / 34 / 6
So in the Example above, the [Sample Report] took 51 seconds total. Remember: this does not include time to queue and run the Event nor the time it took for the Notification to get picked up). It took 8 seconds to turn the selection criteria into a query. It took 34 seconds to fetch the actual data (there are a lot of calculated fields on the [Sample Report], so 30+ seconds is to be expected), and it took 6 seconds to actually generate the PDF file.
See Also the attached .pdf for additional thoughts on reporting speed in RecTrac 3.1
See Attachment: Report Speed in RecTrac 3.1.pdf