On 03/01/2011 04:57 PM, Amos Jeffries wrote:
> On Tue, 01 Mar 2011 16:28:47 -0700, Alex Rousskov wrote:
>> On 03/01/2011 11:29 AM, Tsantilas Christos wrote:
>>> Any comment on this forgotten patch?
> I gave the patch a brief look over earlier when it was submitted and do
> not recall seeing anything major. Please check that it still builds
> cleanly before commit, but that is all.
>
>
> I'm kind of in favour of restricting it to the "process=" parameter,
> instead of two with an overlap.
I would not recommend limiting the cache manager query interface to just
process numbers because it would be increasingly difficult for a simple
script to know which process number corresponds to, say, worker #2.
Currently, it is just workers and Coordinator, but with Rock Store, for
example, we get workers, diskers, and Coordinator kids. And the variety
of kids will only grow with time as some standard helpers become kids
and new kid kinds are introduced.
> Since we give each process a pseudo-unique procID this makes more sense
> and is wider in its support of the planned helper/worker/kid types.
Process numbers are good for blind low-level kids enumeration, but make
intelligent "Are my workers balanced?" or "Does the third cache_dir
receive more traffic?" queries difficult and dependent on internal kid
starting order.
Imagine, for example, asking a bug reporter for stats specific to
cache_dir #3 (which seems to overflow its quota) when the bug report
does not mention how many SMP workers or other irrelevant helpers Squid
has configured. With the proposed interface, it could be as simple as:
mgr:cachedir?diskers=3
Cheers,
Alex.
Received on Wed Mar 02 2011 - 05:02:44 MST
This archive was generated by hypermail 2.2.0 : Wed Mar 02 2011 - 12:00:03 MST