Performance with large printer database

Patrick Spinler pspinler at yahoo.com
Fri Jan 28 10:23:12 PST 2005


Michael Sweet wrote:
> Patrick Spinler wrote:
> 
>> 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.

Unfortunately, our clients are spread across a number (more than a 
dozen) of different subnetworks. :-(

> 
> 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.

I significantly up'ed these parameters (to 1 hour and 4 hours 
respectively.  Unfortunately, I still still unacceptably slow 
performance on the clients.

Within 10 seconds of restarting a test client, the client cupsd quickly 
maxes out the cpu, and becomes unresponsive to basic requests like 
'lpstat -a'.  Issuing such a command will hang for hours.  In fact, I've 
never seen it complete.

Reducing the client from 4 to 1 browsepoll statements still has the same 
effect, it's just more delayed.  After a restart, cupsd takes 
approximately 3 minutes to reach a 100% cpu consumption and become 
unreponsive.

At a cursory glance, this appears to be some kind of a significant 
performance bug.

I'd offer to perform an strace/truss log for you, but I fear the disk 
space required. Is there a debugging build or some other client level 
debugging or testing I could do for you?

Thanks,
-- Pat

> 
> 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.
> 




More information about the cups mailing list