Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

So the manpage for cups-lpd says "large configurations" are a bad idea, but does not elaborate. Does anyone have any experience with using this tool at scale and how it copes?

I'm looking at around 100 printers receiving 3,000 jobs/hour (total, not each).

As a web programmer 50 requests/minute seems trivial load to me, but if it takes much over a second for each of these it seems it will eventually exhaust itself.

Can this work or am I setting myself up for unpleasant support calls?

(The jobs are RAW pass through straight to the printer, if that matters)

share|improve this question

1 Answer 1

up vote 3 down vote accepted

I haven't had any problems with large production printing environments with 100+ printers (running CUPS or LPRng). Is there a reason you're using cups-lpd instead of just using lp/lpr through CUPS?

There are a few CUPS tweaks you can make to ease troubles, though. Depending on your Linux distribution, you will want to change some of the defaults in the /etc/cups/cupsd.conf file.

  • I tend to increase the MaxLogSize value to 2000000000.
  • You may also want to increase MaxJobs to a value beyond the default 500 (I use 5000) or to 0 (no limit). This details the maximum number of jobs to keep in memory (active and completed). If you have a high-volume device fail or stall, but print jobs continue to be submitted, this number can be reached easily and will stall the entire printing system until the queues are cleared.
  • In the /etc/cups/printers.conf, I set the printers' ErrorPolicy directive to retry-job instead of the default stop-printer. This means that small connectivity blips/paper jams/etc. won't result in printers going offline, requiring a cupsenable to resume printing.
share|improve this answer
    
Thanks! We have clients that are are built to basically send hand-spun LPR messages directly to the printer, but some of the printer models do not appreciate concurrent sockets, so the hope was clients could be pointed at CUPS instead and acquire some ability to get things queued properly without having to change the clients. cups-lpd was what I found in the documentation for setting it up to accept arbitrary raw messages from TCP/IP clients. –  Affe Jul 10 '12 at 23:53
    
Most people do not use the cups-lpd package. The CUPS daemon provides a mostly-compatible lp and lpr command interface. I also send RAW to CUPS systems in my environments and Linux handles this well. –  ewwhite Jul 10 '12 at 23:56

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.