With a Self-replicating process that outputs using the Print using a Windows Driver task. Is there any reason that Self-replicating does not work well with the Print using a Windows Driver task? Such as does the Print using a Windows Driver task utilize the Alembic service?
With this process the Print using a Windows Driver task is printing to a dynamic printer to generate a file other than Postscript. Each input file is fairly small, but there are thousands of them. For example with 5000 PDF files waiting to be sent, and the process set to 20% it took over an hour to clear the backlog. Increasing the percentage to 40% appears to be the same performance.
Looking for ideas to tune the performance and if the Print using a Windows Driver task is suitable to use with Self-replicating process.
In your environment, the bottleneck is your Windows queue. You could set it up any way your want, all jobs going to a specific queue will be queued (no pun intended ) and print in order of reception by the queue. In that case, Windows’ print spooler is responsable to dispatch jobs to the printer.
You could send them directly to each printer I.P., via LPR output, provided that your printer(s) are natively able to print PDF.
In that case, the only thing I can think of would be to try merging the PDFs altogether (or small batches) to gain speed by eliminating delay in between jobs. Usually, at the printer, when a job ends and another starts, there is a delay. By concatenating many PDFs together you could save on these delay and add to your total throughput.
The process of printing a PDF through a Windows printer driver is delegated to a third-party library. This library serializes print operations to a single simultaneous thread. This was observed a while ago but I assume that it is the same with the latest version.
Which makes sense, if you think about it. Even if you could multi-thread the printing process, the jobs would still need to be queued to be sent one a the time to the printer. Since the printer is still orders of magnitudes slower than the print job generation and spooling, absolute speed it doesn’t quite matter from the library’s standpoint. So yeah, it might take more time to generate a few thousand jobs, but you’re not affecting the overall throughput.
If that is a problem in your case, I guess it’s because you are not sending the files to the printer but capturing them to repurpose them or have some after-the-fact processing. Am I correct?
We send PDF files to Print Using Windows Driver Task and then take the spool file and send it to an external server. We had a huge volume of 5000+ PDF files waiting to be sent. The process was set to 20% and took more than hour to clear the queue. I tried increasing to 40%, but seems like the output I am getting out of Print Using Windows Driver Task is the same.
Since the bottleneck is the Windows queue, and you are not limited by a physical printer device, you could try to define multiple Windows queues and distributed the PDF across them. I do not know if that case the Windows spooler would become the bottleneck, in which case that wouldn’t improve things.
If this is the case, then you could distribute the PDF across windows queues on different workstation. As long as Workflow as access to those queues, you should get more speed like that.
) and print in order of reception by the queue. In that case, Windows’ print spooler is responsable to dispatch jobs to the printer.