Background: Our print speed in our hosted solution sucks. Is difficult to print a report in under a minute, basic attachments take close to 30 seconds. I’ve identified a list of potential issues and solutions via reading a couple old vantage threads and the Performance Diagnostic and Troubleshooting Guide. In order to test those solutions, I’d like to track how fast we’re currently printing and compare that to how fast we’re printing after implementing each solution. Currently the best way I know to do this is to print various reports from multiple workstations and write down the speed. This is time-consuming and is difficult to get a large sample size. There wasn’t anything in the Performance…Guide about systematically evaluating print performance, only a list of common issues and solutions.
Question: Does anyone know if there is a better way to track print print speed, ideally something that automatically tracks the time it takes for a user to hit print to the time the request reaches the printer?
I’ve been looking for a way to do this also. But have come up blank.
The best I do - to get accurate times - is use the System Monitor.
If you use the Right-Click send to Excel, you’ll actually get the start and stop times with seconds displayed too.
You have to be quick for the first couple of steps, but what I do is:
After hitting Submit from a print dialog, immediately launch the System Monitor (double click the systray icon)
Select the Scheduled Tasks tab and do the Right-click to excel.
Switch to the Active tasks tab and send to excel
After the report finishes, go to the Reports tab, and send to excel.
Basically this will give you the start time of each step (scheduled, running, and rendered). Then you can see how long each step took. Note: this doesn’t give an accurate value of the “between steps” times. I often get the Balloon pop-up on the sysmonitor taskbar icon, and still wait 5 or more seconds for the preview to render.
If you’ve security exec privileges, you can select Actions -> Display all tasks in the System monitor, to see other users reports.
And FWIW - waiting for the Print dialog box (after clicking the Print icon for a local printer) can take upwards of 2 minutes. We just use Print Preview for everything, and then print from the Acrobat Reader window. Supposedly, the long delay is the client program searching the network for available printers.
aidacra
(Nathan your friendly neighborhood Support Engineer)
3
Below are the basic tests to determine what piece of the printing process is taking the longest. Automating the timing info is definitely possible.
Record the time for how long it takes to print preview this report.
This includes the time it takes for Epicor to generate the xml file, copying that xml file and the Crystal rpt to the workstation, and the time it takes to render the results.
Record the time it takes for the xml file for this report to be completed.
Print preview the same report with the same parameters, and monitor how long it takes for the xml file to be completed in the epicordata\reports\user_id\ folder - this is how long it takes Epicor to generate the data and the general, this is the only part of the process where there are tuning options available from Epicor Technical support to increase performance.
If this part of the process is a concern, please contact technical support for tuning options that could include adding an additional print appserver and adjusting the system monitor polling on the client workstation.
If you subtract the results of test 2 from the results of test 1, that is how long it takes your environment to copy the xml file and rpt file to the client workstation(network and disk i/o on the server and workstation), and how long it takes the user’s workstation to render (processing on the workstation). You can try to run this test on the server instead of a workstation to see if there is a difference; if there is, the hardware on the client workstation may be the cause of the slow down.
Record the time it takes to print from the print preview.
This includes the time it takes for Epicor to generate the xml file, copying that xml file and the Crystal rpt to the workstation, how long it takes to render the data and how long it takes for the printer to actually print the report.
The difference in time between the first test and this test is the environmental time after the workstation has received the files and rendered the data, and how long it takes to print the report on your network. The causes for a longer than expected time for this test could be network connectivity or perhaps the speed of the printer, but if this amount of time is a concern you can contact our professional services team for assistance (their services are billable) to help determine the root cause and potential changes to improve this part of the printing process.
Thanks guys. Didn’t realize that the dialog box can take that long. Thought ours was slow, but just timed it and was about 6 seconds.
I haven’t tried your steps 2 and 3 aidacra, so I’ll try those. You said “automating the timing info is definitely possible”. Do you mean that there’s a way to automatically measure the time in steps 1-3? Right now I’m assuming for step 1 I’ll just use a stopwatch, for step 2 I can compare start time in System Monitor to the time the XML was created, step 3 will need stopwatch again.