[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,

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