1
votes

We have an application that prints small dockets all the time. The dockets are Crystal Reports. We have about 10 different docket designs and layouts.

There is no data access done from CR, we process and pass all the data to the report document as an ArrayList.

We have measured massive lag spikes in the PrintToPrinter function. As you can see in this chart, they seem to increase over time:

Chart showing lag spikes in PrintToPrinter

The blue lines show the time PrintToPrinter took to complete in seconds. Most of the time it is under 1 second but some times it takes up to 200. Orange lines are points where the application was started.

Interestingly we also tried changing PrintToPrinter with ExportToDisk (PDF) and the spikes seem to happen with a similar pattern.

This is a chart from another machine using ExportToDisk(PDF): Chart showing lag spikes in ExportToDisk(PDF)

Some additional information:

  • Users report that when lag starts to happen they can "unfreeze and get it to print" by clicking repeatedly on the application surface.

  • There are no antivirus programs running on these machines.

  • This issue has been impossible to reproduce in non production environments. We only rely on logs, but it seems to happen on different environments (Windows versions, printers, PCs).

  • We tried caching the report document objects and it had great results on only a couple of machines but generally it was worse.

1
How are you cleaning up after each print? Are you properly disposing of the report document? What version of the Crystal runtime is it? Have you tried the client document API PrintReport method? - reckface
Hi, we are using the developer version for Microsoft Visual Studio SP 12. We call reportDocument1.Close() and reportDocument1.Dispose() after each print. - Antonio Dlp

1 Answers

0
votes

Based on what you have said here, I would be of the opinion that "the culprit is probably not Crystal Reports." I think that you are observing some kind of external influence, completely unrelated to Crystal (or, quite likely, to any other "piece of software." I would suggest looking at other types of logs ... system logs.

In considering what might be the root cause of this most-curious problem, my first instinct would be to "not give too much credence" to the user's reports that they can get it to un-stick by clicking the mouse. It could be relevant, but it could just as easily be a(mother) red herring. (When users are trying to get a computer to stop being unresponsive, they either bang on the keyboard or click on the mouse ...)

Obviously, "if something causes a computer to wait for more than two minutes," that something is probably some kind of: timeout. Probably somewhere in the printing subsystem. And it seems to me that the printer subsystem and/or the general system logs of those computers should have produced some kind of message or event-log that can be matched-up very precisely with the exact times when these problems occur.