On 13/01/2013 6:11 a.m., Alex Rousskov wrote:
On 01/11/2013 09:42 PM, Amos Jeffries wrote:
On 12/01/2013 1:39 p.m., Alex Rousskov wrote:
And should we use n_running or n_active for these checks?
I think we should get away from the 2*N logic entirely and do something
a bit safer.
As it stands n_active AFAIK is the intended measure. n_running includes
helpers being shutdown, so when they disappear the queue magically
overflows. However if any one of the n_active helpers has a problem they
get removed from n_active and the queue again magically overflows.
Sounds like neither "current n_active" nor "current n_running" is a good
measure for overflows because both may go down rather abruptly and
without admin control.
Perhapse something like 2*n_max would be better, at least that is a
fixed lengh of queue independent of what is happening with the helpers.
I am not a helper expert, but stable and directly-configurable n_max
does make more sense than dynamic and hidden n_running/n_active IMO.
In addition to that, I know of at least one use case where they have to
patch Squid sources because they believe their helpers need a different
limit than 2*n_something (and perhaps to fix some inconsistencies).
TODO: There are approximately ten places where we check queue sizes
against n_running or n_active. Many of those checks are slightly
different. This inconsistency should be removed, probably by adding a
few standard methods for a few types of checks that are actually needed.
Patches welcome!
+1 on that idea.
I suggest to:
1. Make the queue limit configurable, with the default set to 2*n_max.
2. Move common queue limit checks into a few methods.
3. Make all code to use those new methods.
With such a combination, Factory may even be able to sponsor the
development.
Any better ideas?
Sounds like a good plan.
I'm available to write it up if you are going to sponsor.
Amos
