When cups-polld polls a remote server for printers, it avoids sending all of the discovered printers to the local cupsd at once, supposedly to avoid overwhelming the local server.
To do this, it will only send "(number_of_remote_queues / value_of_BrowseInterval) + 1" queues per second.
However, if BrowseInterval is sufficiently large and the CUPS server has just been started, this causes a long delay while polld slowly feeds all of the queues to the cupsd.
In our environment, we set BrowseInterval to 600 to avoid unnecessary load on our central print server. However, this means that the first tiem we start CUPS, our workstations only discover 1 printer per second.
I haven't seen any obvious issues that look like the local cupsd gets overloaded if I set BrowseInterval to 1. What exactly is the concern with overloading the server? Could the code to throttle requests be dropped these days?
Alternatively, could cups-polld be modified to not throttle discovered queues the first time it runs?
The text was updated successfully, but these errors were encountered:
Ok, so the issue is that cups-polld uses the CUPS browse protocol to relay remote queues to the local cupsd. Since that is UDP, it is possible to lose printers if cupsd doesn't process the packets fast enough.
That said, we certainly can enforce a higher minimum number of printers per second. 10 or 20 shouldn't be a problem.
so it seems at first glance that cupsd is happy to send broadcasts at twice the rate that cups-polld will send them to the local cupsd, and as BrowseInterval goes up the rate of adverts per second goes down by it's square (since there are fewer adverts sent each time and spaced further apart).
Also the rate goes up for servers with more printers.
Am I completely misunderstanding what the code does?
Would it not make sense to just have a fixed number of adverts it will send in each interval? Perhaps a user configrable option (say) BrowseAdvertsPerInterval or similar?