Each step in the SavaPage Proxy Print Workflow has critical factors that influence overall performance.
The major steps in the workflow in a nutshell:
|1||User||Send Print Job request to CUPS Scheduler.|
|2||CUPS Scheduler||Schedule print spooling.|
|3||CUPS Spooler||Hold print job in queue, send to Filter when Printer is available.|
|4||CUPS Filter||Convert PDF into PDL1) (PostScript, PCL, etc.) and send to Backend|
|5||CUPS Backend||Send PDL to the Printer.|
|6||Printer||Convert PDL to bitmap dots on paper.|
Each step is detailed in a section below.
The PDF document to be printed and the printer settings, chosen by the user, are translated to an IPP Print Job request and, via HTTP POST and
application/ipp content type, send to the CUPS Scheduler.
The maximum number of simultaneous clients and print jobs that can be supported is primarily limited by the available server memory, file descriptors, and CPU - the CUPS scheduler itself imposes no hard limits.
|Concurrency||Many user requests within a too short time window lead to long waiting times.|| Add CPU Cores, so CUPS filter processes can run concurrently.
For example, a university uses 12 CPU cores for load balancing CUPS filtering for thousands of students printing with SavaPage.
A CUPS Printer Class is a group of printers, and acts as a regular printer from a user's point of view. When printing to a class, CUPS will redirect the job to one of its members. Which member would depend on user rights or which printer currently is available.
|Concurrency|| Many user requests to a single || A printer class, with multiple
Filtering PDF to PDL is a CPU intensive process: CPUs with higher clock rate will get the job done faster.
|Content||Filtering multi-layered PDF (CAD), graphics and special fonts, takes longer than plain text.||CPU with higher clock rate.|
|Volume||Filtering many pages take longer.||Set limit on page volume to print freely. Print large PDFs by Job Ticket only.|
|Settings||Filtering for higher print resolution take longer.||Set low resolution (300 dpi) as printer default.|
|Driver||Filtering with vendor drivers may take many times longer than with Generic PostScript drivers (see table below).||Test vendor specific CUPS driver before purchasing printer. Or, use Generic Postscript Driver when simple printing (without vendor features) is sufficient.|
The table below shows some CUPS filter duration metrics of mixed content PDF with different PPD drivers. savaspool.sh was used to capture the spoolfiles.
|Content||Driver||Pages|| 3.40GHz 2) |
| 2.67GHz 3) |
| 2.00GHz 4)
|text + graphics||Generic PostScript Printer||9||0.01||0:02||0:03|
|Xerox D125 Copier/Printer (PS)||9||0:03||0:04||0:06|
|Canon iR-ADV 8285/8295 UFR II||9||0:07||0:10||0:16|
|text + graphics||Generic PostScript Printer||51||0:18||0:35||0:51|
|Xerox D125 Copier/Printer (PS)||51||0:58||1:50||2:35|
|Canon iR-ADV 8285/8295 UFR II||51||1:48||3:25||5:00|
The CUPS backend sends the filtered PDL data to the printer, over the network or via usb, serial or parallel port. The Printer URI start with a backend identifier, like
serial:. Printing to a Windows Print Server queue is done with the Samba
As backends can be chained, PaperCut Print Management 5) has its own
papercut: backend to put in front of any other backend.
So, in the
papercut:socket://192.168.1.66 URI, the
papercut: backend is the first to receive the filtered PDL data. In this way PaperCut checks print job parameters against custom print policy first and, when printing is approved, sends the PDL data to the
To analyze the print job,
papercut: must process the complete incoming PDL stream in advance, before it can stream the PDL to the next backend in line.
In some cases, this policy can seriously delay printing, since
stdout of the CUPS filter is not one-to-one streamed to
stdin of the final backend sending data to the printer.
As an example, the table below shows the 2-step CUPS filter process of the Canon iR-ADV 8285/8295 UFR II driver on a 2.67GHz CPU for a 51 page text + graphics PDF document. Metrics were obtained by observing
top and printing with savaspool.sh backend.
|2||Canon UFR II Driver||PostScript||OpenPrinting Vector||1:48|
In the Canon case, the papercut: backend introduces a 1:48 m:ss extra delay before the first page starts printing.
Network speed is a factor when sending PDL data to a network printer.
When printing to a PaperCut hold/release CUPS queue, spool files are stored to disk waiting to be released. These spool files can be quite large: sizes of 1GB+ are no exception. If the hold/release time-out is long (a day or more), you need to plan for additional disk space.
When the PDL data (spoolfile) arrive at the printer it must check and prepare all hardware involved, before it starts printing the first page. Like, is paper path clear (any paper jams), are media sources and output bins ready, etc. When in sleep mode, it must warm up the fuser. This might all take a few seconds, or longer, depending on how fast the printer is.
The rendering of PDL into bitmap dots-on-page might be a slow process: if the printer is low on memory, it must swap to disk or wait for a page to finish, before it can start rendering the next one.
When memory or disk space is insufficient, the printer may reject parts of the PDL, and print error messages instead. For example:
ERROR: ioerror OFFENDING COMMAND: image STACK: --nostringval-- -mark- -mark- -mark-
Finally, print job options like duplex, color, high quality, and finishings (staple, hole punch, booklet) have an overall impact on the page-per-minute performance of the printer.
papercut:backend can slow down first page printing.