Troubleshooting Slow Printing

KB Home   |   Troubleshooting Slow Printing

Main.SlowPrintingTroubleshooting History

Hide minor edits - Show changes to output

April 04, 2019, at 07:32 AM by timg - Created article
Added lines 1-103:
(:title Troubleshooting Slow Printing:)

!!Does PaperCut slow down printing?

PaperCut briefly pauses print jobs to analyze the job, but it's normally so quick that even if you're watching the print queue, you have to be fast to catch it! In short, [[|no one should notice]] at all - so if you're seeing slow printing with PaperCut, it's definitely not normal.

Most of our questions around slow printing are around how to narrow down where the slowness is happening.

!!Does the issue occur without PaperCut?

For testing purposes, tell PaperCut to [[|ignore the printer]], or you can [[|stop the PaperCut Print Provider]] service on the print server that you're printing to (maybe do that one out-of-hours if you're in a production environment, since it'll mean that no jobs are tracked by PaperCut while the service is stopped).

Once PaperCut is removed from the equation then try sending a test job:
*''Note'': even though the test needs you to bypass PaperCut, it's essential that the job still follows the path that it took before. For example if you're printing from your workstation, through a print queue on Print Server 1, to a printer; don't print from your workstation to the printer directly, in an effort to bypass PaperCut to test. You'll have to make sure that you print from your workstation, to the same queue on the print server, to the printer (just make sure you've disabled PaperCut in one of the ways above).
Does the document still print slowly? If so, the problem is probably unrelated to PaperCut - but that doesn't mean that we're no longer interested. Printing's in our blood, so we still want to figure this out. Some common scenarios are:
*The printer itself is having a mechanical issue.
*The user tries to print an extremely complex, unflattened PDF or vector file, which takes a long time to render (we often see this with graphical / design departments).
*The print server is too busy and does not have enough resources.
*Slow network connection between the workstation and print server (like in this blog post about [[|diagnosing a slow print job]]).

!!Is the print job slow to spool to the print server?

!!!Is the print server hosted in the cloud, or on a network that's 'far away' in terms of network connection / latency?

If so, the problem may be based in the architecture of the print environment and would still occur without PaperCut altogether. There are alternatives in this case where building a secondary print server at the remote site can help performance for users in both the remote site and the local site. There's some great visual examples of network types in the [[|multi-site and WAN]] section of the manual.

This is not only great for performance, but can also mean that cross-site links can be freed up for more critical traffic like VOIP or file sharing.

!!!Are the spool files extremely large?

Spool files can be huge if an end user tries to print an entire textbook, or if they try to print a multi-layered PDF or vector images. Sometimes the applications in question allow users to flatten the PDF before printing - which can drastically reduce the size of the spool file.

!!!Is it also slow to connect to shared print queues from a Windows Print server?

If so, are Windows Print Spooling Ports blocked?

The Windows Print Spooler service uses a high dynamic TCP port range in between 49152 - 65535. However, when these ports are blocked it may delay jobs around 40 seconds while a different port is negotiated, and the client will fall back to the Windows 2003 range of ports. This is a problem that will occur without PaperCut and may happen when workstations try to add a printer, try to send a print job, or when we attempt to do cross-sever redirection.

To confirm, open a command prompt window and run netstat -b -n on the print server to show which ports the spooler is using. If spoolsv.exe is using 445 and 139, instead of randomly assigned ports 49152 through 65535, there may be a problem.

Make sure that ports 49152-65535 are whitelisted on the firewall inbetween clients and the print server.  After making that change it may be necessary to restart the Print Spooler service via the services.msc manager.

!!Or is the print job slow to release to the printer?

!!!Is the print queue set up to use the PaperCut TCP/IP instead of a Standard TCP/IP port?

Don't use the PaperCut TCP/IP port, unless it is absolutely necessary for [[|hardware checking]]. This will slow down printing by design as PaperCut will wait until the printer reports that the last job was printed before sending the next one.  The best advice is to avoid the PaperCut TCP/IP Port whenever possible and use a Standard TCP/IP Port.

Take a look through [[|How Does Hardware Checking Affect Printing Speed]] for a deeper dive into this subject.

(If you must use the PaperCut TCP/IP port, make sure you disable bi-directional support in the Windows Print queue!).

If you're ''needing'' to use hardware checking, and are finding the release of jobs to be slow, there is one final trick. This is definitely more advanced, and we recommend keeping things default where possible - however you can configure the number of loops that we wait for the device to report as 'idle' while waiting to print a new job, and after a printed job finishes. These are the 'beforeloops' and 'afterloops' respectively.

Warning: Make small changes at a time, and test thoroughly:
In the print-provider.conf file on your Print Server where the PaperCut Print Provider is installed, head into:
@@[[=AppPath]=]\providers\print\[platform]\print-provider.conf@@ and add lines where necessary:
*[=HWCheckModel1=model="manufacturer or model" beforeloops="3" afterloops="3"=]
*[=HWCheckModel1=model="Toshiba" beforeloops="4" afterloops="3"=]
This is a per-vendor setting, up to 5
*[=HWCheckModel2=model="manufacturer2" beforeloops="2" afterloops="3"=]
*[=HWCheckModel3=model="manufacturer3" beforeloops="3" afterloops="2"=]

!!!Is the print queue using a WSD port?

If the printer is using a WSD port (you'll see the port description listed as 'WSD Port'), the protocol is not really designed for enterprise print environments. If [=IPsec=] is enabled on the print server the device has to respond back to the print server with information about print job status.  If that data is blocked for some reason, then the Print Server will never get the status from the device. The effect is that the Print job will be stuck as "printing..." in the Windows Print queue. The same thing will happen whether you're using PaperCut or not!

!!!Is slow printing only an issue with Sharp copiers?

This can happen in rare cases with certain Sharp copiers, and it's worth checking the [[|Slow Printing on some Sharp Copiers]] article.

!!!Is Print Archiving enabled on virtual printers on secondary servers?

If you're seeing delays with releasing jobs, and you have [[|Print Archiving]] switched on for your print queues, there can sometimes be delays.

Spool files are not copied to the App Server (the archive) until the job is actually released. They are not copied when the jobs are cancelled by the user, or if they time out in the hold/release queue. On slow uplinks to the application server, there can be a delay on release before the print job is sent to the target printer. 

!!!Is the slow-release only happening when using cross-server redirection?

Cross server redirection is when you print to a find me queue on Server 1, and then you release the job to a print queue hosted on another server. PaperCut then redirects the job from the source queue on Server 1, to the target queue on the different server.

In the case of slow release, because PaperCut calls the target printer to get the driver name - if you are '''not''' using [[|PDL transforms]], then:
In the print-provider.conf file on your Print Server where the PaperCut Print Provider is installed, head into:
@@[[=AppPath=]]\providers\print\[platform]\print-provider.conf@@ and add:

!!Are you looking to cut down on network traffic in general?

If you're really wanting to hone in on certain 'power users' who may be generating massive spool files due to the nature of their print jobs, one option is to configure the [[|Direct Print Monitor]] for those few users in question. The advantage of this is that those users can print direct from their workstation to the printer - but ''still'' have their jobs tracked and managed by PaperCut. Everyone wins!

There may also be cases where you want to enable data compression over certain links in the network - if so, it's worth reading through our [[|Improving Slow Printing with Data Compression]] article.


!!Still have questions?
Let us know! We love chatting about whatís going on under the hood. Feel free to leave a comment below or visit our [[|Support Portal]] for further assistance.

''Categories:'' [[Category.Troubleshooting|+]], [[Category.Printers|+]]
[-Keywords: slowness, slow print job, printing is slow, slow performance -]


Share your findings and experience with other PaperCut users. Feel free to add comments and suggestions about this Knowledge Base article. Please don't use this for support requests.

Article last modified on April 04, 2019, at 07:32 AM
Printable View   |   Article History   |   Edit Article