[cups] cups-lpd performance and scalability?

Tim Mooney Tim.Mooney at ndsu.edu
Tue Aug 25 13:32:04 PDT 2015


In regard to: Re: [cups] cups-lpd performance and scalability?, Tim Mooney...:

> In regard to: Re: [cups] cups-lpd performance and scalability?, Michael...:
>
>> We've addressed the major, easy-to-fix performance issues with cups-lpd,
>> but it is still run for every connection/request made by a client,

Just to close out this thread:

It looks like we won't need to enable cups-lpd, as we have been able to
work around the issues that were causing IPP submission problems for us.
The fact that both Helge and Rick indicated that they had it working with
slightly newer versions of cups caused me to try RHEL6's cups 1.4.2 (+
vendor sauce, to borrow a great phrase from Michael).

Michael, my offer to provide a patch for the cups-lpd man page still
stands, if we can arrive at some text that is more current/accurate.

Should I open an STR and work on it that way, or just let it drop?

Thanks everyone for the info you've provided!

Tim

> Definitely understood.  The start up cost for a new inetd/xinetd fork/exec
> for each connection to port 515 is I'm sure a big part of the issue.
>
> I was kind of hoping that someone would chime in that they had written a
> version of cups-lpd that functions as a standalone daemon, and either does
> its own fork/exec or is threaded.  That would at least avoid some of the
> startup costs for each connection.
>
>> and
>> it is still LPD - no security, extremely limited functionality and error
>> reporting, etc.
>
> While IPP would definitely be better, limited functionality beats having
> OS X clients not able to submit jobs at all.
>
>> It works, but we don't recommend using it when you need to support large
>> numbers of simultaneous clients because it can very easily bring your
>> server to its knees...
>
> Thanks for all the info you've provided.  It's definitely food for
> thought.
>
> Tim
>
>>> On Aug 22, 2015, at 7:32 PM, Tim Mooney <Tim.Mooney at ndsu.edu> wrote:
>>> 
>>> 
>>> All-
>>> 
>>> I've downloaded the cups mailing list archives and spent quite a bit of
>>> time grepping them for anything related to cups-lpd, but I don't see where
>>> the question I have about cups-lpd scalability has been addressed before.
>>> 
>>> Because of the problems we've run into with Macs running Yosemite not
>>> being able to submit print jobs to our cups 1.3.7 print server via IPP,
>>> as described in these threads:
>>>
>>>        http://www.cups.org/pipermail/cups/2015-August/027009.html
>>>        http://www.cups.org/pipermail/cups/2015-August/027012.html
>>> 
>>> We're therefore exploring enabling cups-lpd, so Macs and any other systems
>>> that can't do IPP 1.1 can submit print jobs to our cups 1.3.7 server.
>>> 
>>> The cups-lpd PERFORMANCE section has some pretty dire warnings about
>>> cups-lpd not scaling, though.  However, web searches I've done for
>>> "cups-lpd performance" have turned up
>>>
>>>        https://bugzilla.redhat.com/show_bug.cgi?id=132949
>>> 
>>> which leads to this CUPS STR:
>>>
>>>        http://www.cups.org/str.php?L804
>>> 
>>> That implies that a lot of the original cups-lpd performance issues were
>>> resolved in the 1.2 series when cupsGetDests() was improved.
>>> 
>>> Does that mean that the performance warnings in the cups-lpd man page
>>> are (somewhat) out of date?
>>> 
>>> Does anyone have any idea how cups-lpd scales, when used in a mixed
>>> IPP and LPD protocol environment?  We've converted our Windows labs to
>>> use IPP exclusively, so the majority of jobs submitted to our print server
>>> would be via IPP.  If cups-lpd is still a poor performer, though, we don't
>>> want to enable it and cause problems for IPP job submittal too.
>>> 
>>> Thanks much for any information you can provide!
>>> 
>>> Tim
>>> --
>>> Tim Mooney                                             Tim.Mooney at ndsu.edu
>>> Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
>>> Room 242-J6, Quentin Burdick Building                  701-231-8541 (Fax)
>>> North Dakota State University, Fargo, ND 58105-5164
>>> _______________________________________________
>>> cups mailing list
>>> cups at cups.org
>>> https://www.cups.org/mailman/listinfo/cups
>> 
>> _________________________________________________________
>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>> 
>> _______________________________________________
>> cups mailing list
>> cups at cups.org
>> https://www.cups.org/mailman/listinfo/cups
>> 
>
>

-- 
Tim Mooney                                             Tim.Mooney at ndsu.edu
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, Quentin Burdick Building                  701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164



More information about the cups mailing list