[cups.general] Maximum number of printer queue's

[Johannes Meixner]

Hello,

On Apr 18 12:08 Johannes Meixner wrote (shortened):
> Perhaps even with raw queues a CUPS server might be slower
> than an iPrint server - perhaps noticeable only above a
> certain number of print queues or simultaneously active
> print jobs - perhaps only with CUPS 1.1 or whatever?
> Currently I don't have comparison data for this case.

CUPS 1.1 (which we provide in the Suse Linux Enterprise Server)
and CUPS 1.2 use the system call select(2) which cannot handle
more then 1024 file descriptors.

For the consequence (here it seems for CUPS 1.2) see
http://www.cups.org/newsgroups.php?s1+gcups.general+v2+T0+QWhyhasnothingchanged%3F
------------------------------------------------------------
Right now the scheduler has 3 file descriptors open while
a job is printing (backend pipe, back-channel pipe,
stderr pipe) which limits the maximum number of
simultaneously printing jobs to about 230 with the
typical 1024 file descriptor limit.
------------------------------------------------------------

As far as I remember CUPS 1.1 has no back-channel file
descriptor so that with CUPS 1.1 about 300 simultaneously
printing jobs should be possible.

Furthermore - if I understand it correctly - the select limit
applies both for incomming jobs and for active printing jobs.
I.e. the total number of simultaneously processed jobs
(regardless if incomming or printing) is limited by one
single select limit. 

Therefore at least for CUPS 1.1 and 1.2 there is a certain
hard limit in the underlying Linux operating system why CUPS
cannot "scale to meet the needs of enterprise customers"
(e.g. print 500 jobs and simultaneously get 500 new jobs).


Since CUPS 1.3 the scheduler uses poll(), epoll(),
or /dev/kqueue instead of select() when possible.
See
http://www.cups.org/str.php?L1261
for background information.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex