Posted 4 August 2017, 2:45 pm ESTWe recently upgrade from AR1 to AR2 after 6 years of successful AR1 usage. We didn't notice any problem during Dev and Testing phases. As soon as we moved to more powerful "Production" servers we have experienced huge memory footprints (500 meg for simple report) and severe slowdown (probably side effect of memory consumption) with AR2. Do you have any idea what could cause this? We are trying to determine differences between our servers because our test environments do not show the memory issue, but so far the only difference appears to be CPU and memory. The more we have, the worse results with AR2?
Memory and Speed issues with AR2?
Posted by: bluequote on 4 August 2017, 2:45 pm EST
Replied 4 August 2017, 2:45 pm ESTThanks for your response. I've attached the simple test app we created to isolate our problem to AR2. Can you check this out and see if we are doing something wrong. The example doesn't use any subreports. The memory footprint jumps to 500 meg on our good servers, it is only about 15 meg at most on our smaller servers.
Takes 8 seconds to loop through report 7 times on "good servers", only two seconds on our smaller servers and less than a second on my smaller desktop.We are on build 220.127.116.113
Replied 4 August 2017, 2:45 pm ESTWhat build of AR2 are you using? Are you properly disposing the report objects?
Be sure you set all of the subreport instantiations on your report to nothing in OnReportEnd. See the following thread and threads it references for more details:
Following these guidelines should ensure that no resources are left to build up between report creations.
Replied 4 August 2017, 2:45 pm ESTI am unable to run this sample, as I am missing your "Regstration Manipulation Classes". In looking at the code, I would like to suggest the following:
- Avoid using a global Show event (as in modCleaner - although I do not see this being called from anywhere).
- Avoid using the global report instance. Create a New report object before your loop:
Dim rpt as SiebelGroupReport
then, within the loop:
Set rpt = New SiebelGroupReport
and change your other SiebelGroupReport references to rpt.
- In clsCleaner, after calling SiebelGroupReport.Run, add the following line:
- To eliminate possible printer issues, set rpt.Printer.DeviceName = "" within your loop right before Run False.
- Do not place your DLL in COM+:
I would also like to recommend trying the newest build if possible to see if it improves your situation at all:
Replied 4 August 2017, 2:45 pm ESTrpt.Printer.DeviceName = "" seems to have fixed our problem in my little test application. We will try it in our main application to see if that does the trick there, but so far looks good.
Thanks for your help!
Replied 4 August 2017, 2:45 pm ESTTurning off the "Print Spooler" on our servers also solved the problem, though we are making the code changes you recommended as well.
The examples above are fixing reports that don't have sub Reports. Can you tell me what we could be doing wrong with subreports. Here's an example:
Private Sub Detail_Format()
Set srptcover1.object = New ARptCoverHiLo
Private Sub ActiveReport_ReportEnd()
Set srptcover1.object = Nothing
Is there anything else we need to do to dispose of subreports? Do we need to set each subreports printer.devicename = "" also?
Replied 4 August 2017, 2:45 pm ESTThe code you show should dispose of the objects correctly. The subreport should probably be set to nothing too. Setting the deviceName to an empty string probably isn't necessary, but it wouldn't hurt.