VB6/CR 8.5/Windows 2016 - Report Exports to CSV Much Slower than on W2012R2.

[JohnR_ORL]

We have a number of Windows 2012R2 servers running a VB6 application that includes Crystal Reports 8.5 APIs and everything's been working fine. With 2012R2 going end of life soon, we've been switching the application onto 2016 servers.

Things are generally going well, except for some users that run reports and then export the data to CSV files. Export times have increased dramatically. In one case 5 minutes to 40 minutes, and in another 1.5 hours to 11 hours.

Does anyone have any idea what might be going on here? (and how we can fix it)

[vb6forever]

I'll take a shot in the dark, but my guess is it is WIA, because of the printer and printer driver.
Just did some research on this last night. FWIW M$ offers up in the WDK a tool to test this.

https://learn.microsoft.com/en-us/wi...a-09a93f32fe93

Your might shut off WIA and then start it manually just before printing and see what happens.

Hopes that solves your problem.

[JohnR_ORL]

Thanks.

I looked into this. WMI is present on the new servers but not the old ones. It is not running on the new servers by default. I tried starting it and then ran a big export but the speed is coming up the same.

[OptionBase1]

There's not nearly enough information to give more than "Shot in the dark" suggestions.

Are there significant underlying infrastructural changes in the servers? For example, were the 2012R2 servers running on beefy physical servers, and the new 2016 servers running on VM's?

Did the disk infrastructure change? For example, were the old servers running locally attached drives, and the new servers connected to some sort of shared NAS storage?

Did the database method of access change? For example, did the underlying data exist directly on the old servers, and the new servers are pulling data across the LAN?

There's other questions like that that may be relevant, but those are the three most significant ones I could come up with off the top of my head.

[jdc2000]

Are you using new/different anti-malware software on the new systems?

It might be an idea to add some logging capability to the VB6 software to see where exactly the slowdown is occurring. During the data acquisition or queries, report generation, the Crystal Reports functionality, or .csv export. Log the function being executed, and the date and time for each step.

[JohnR_ORL]

I guess I've been living this thing for the last little bit, so I didn't think about passing on a lot more information.

We're running in AWS and are simply moving from a W2012R2 server there to a new W2016 server. The application has not been changed and is installed fresh. Size and configuration-wise things started out the same from the old to new servers. Beyond that we've tried increasing what we could. We doubled the size of the server, we added network capability (IOPS, from 3k to 10k), and we increased the Virtual Memory (I'm not sure what the setting was for that). Nothing affected the Export speed. It's kind of maddening.

I terms of logging and how things operate, there's not much to look at. We build up a CR Viewer object, execute it, and then drop into a While loop that just keeps hitting the CR DoEvents call. Everything after that is from the CR subsystem. In terms of report design, it does hit a stored procedure to retrieve the data. Some reports have formulas in them, and some do not.

Data acquisition seems to work fine and no slowdown is observed there. We can see all the data in the CR viewer, and it's relatively quick to jump to the last page. It's the part where we export it that's taking all the time. From what we can see that doesn't involve re-acquiring the data.

[vb6forever]

Since it appears to be an output issue, I still point to WIA.
Just found a free piece of software for testing my scanner.
Can invoke TWAIN (scanner didn't support)
WIA 1.0 hung and couldn't get properties
WIA 2.0 got properties but scan hung, interesting when I pulled the USB and plugged back in the scanner finished.
Based on my readings WIA is using streams, and most older and some newer device drivers are not setup to handle this. In researching found someone did lot of troubleshooting. Had multiple HP printers.
All worked except one with WIA, but the device driver for one had problems and hangs. Why diff in WIA driver code??

[JohnR_ORL]

After working on this for a while, this looks to me like some sort of throttling or speed limitation somewhere in the AWS infrastructure. But, we have a workaround. I eventually tried exporting the large reports to a DFS share and my speed improved dramatically. What was taking 4 minutes is now taking 1 minute or less, which was about our previous speed.

My thinking on this is that our speed issue is caused by some sort of throttle or limitation in some layer of the AWS stack. We had been exporting to the "local" hard drive for testing thinking that would have the shortest path and best response time. But of course this being a virtual machine, that local storage could be anything anywhere. It would be nice to know where the slowdown is/was, but with a reasonable workaround everyone is just eager to move on.