Performance with large printer database

[Michael Sweet]

Patrick Spinler wrote:
> Hi:
> 
> I'm attempting to run a 4 node cups server cluster, cups 1.1.23-1 on 
> redhat enterprise 3.
> 
> Our printer database is currently about 6000 definitions long.  This is 
> identical on each of the servers.
> 
> On the servers, lpstat -a returns a list of all 6000 servers in about 8 
> seconds.   A wget of the cups admin printer list page returns in about 
> the same amount of time (although mozilla takes about a minute to parse 
> and display that page. :-)  ).
> 
> As a test, I've set up a solaris 8 and a linux FC2 client, each running 
> a cups-1.1.23 package, with 4 BrowsePoll directives in each client's 
> cupsd.conf, one BrowsePoll for each of the print servers.
> 
> what I am finding is that when I start the cups daemon on the client, it 
> immediately shoots to near %100 of the cpu, and stays there for hours 
> and hours.  during this time, it is wholely unresponsive to any request. 
>  For instance, I can't do a lpstat, or lpr, or anything, on the client. 
>  any such command simply hangs.
> 
> Please advise me.  What, if anything, can I do?

First, unless your servers are on a different network, it will be
MUCH more efficient (read: less network traffic, faster client
responses) if you don't use BrowsePoll on the clients, and instead
just use BrowseAddress on the servers.

Second, tune the BrowseInterval and BrowseTimeout parameters; the
defaults are usable up to about 100 printers (which yields 3-4
printer updates per second).  If you have the defaults set on the
client, then they will be processing 800 printer updates per
second, which *will* bog the systems down.

Third, be prepared to need a lot of RAM on the clients; 4 servers
with 6000 printers apiece will yield 30000 printers on each client
if you have implicit classes enabled, which will need ~60MB of memory
to track them (the current overhead is ~2k per printer...)

You can split the printers up (e.g. so that each server handles half
of the available printers) to realize similar redundancy and load-
balancing but cut the memory, CPU, and network overhead on the
clients.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com