[squid-dev] What is your opinion: Debugging and cache enhancement tool, what is the preferred implementation?

[Alex Rousskov]

On 11/19/2015 03:54 AM, Eliezer Croitoru wrote:
> I have two options:

> - adding code to squid which with a on\off switch(can be some
> debug_options level) will add an informative header... like many CDN
> proxies does already.( returning the latest StoreID that is being used
> by squid, since squid changes the StoreID in some cases after the
> response started... "Vary" etc)

> - Writing an ICAP service that will do the trick by adding these
> informative headers externally based on the understanding of squid
> internals.

I do not recommend implementing either of the above options.


> If you have another idea how to implement the idea let me know.


There are two different aspects of the problem you are trying to solve:

1. How to _enable_ debugging of caching decisions for transaction X.
2. How to _relay_ caching decisions for transaction X to the admin.


1. For the first part of the problem, debug_options are too crude and so
will be any on/off switch you might add. To be usable in production
(high background volume of irrelevant transactions while you want to
triage only one or a few), this has to be done using a new ACL-driven
directive. We may call it "triage" and eventually expand its use to
cases beyond caching:

  triage caching acl1 acl2 ...
  triage peering acl3 acl4 ...
  triage acls acl5 acl6 ...
  triage all acl7 acl8 ...

The new directive should probably be evaluated a few times during master
transaction (and the corresponding connections) lifetime: client
connection acceptance, virgin request headers parsed, adapted request
headers parsed, server connection establishment, virgin response headers
parsed, adapted response headers parsed. The matching connection and
master transaction should be marked as such.


2. Now to the second problem: In general, "Why was [not] request X
served from cache?" and "Why was [not] response Y cached?" questions are
often nearly impossible to fully answer using "an informative header".
There is often just too much information to conveniently relay using an
HTTP header value. For simple cases, we already have X-Cache headers. As
you know, they do not solve the problem. We need detailed debugging.

On the other hand, headers conveniently isolate triage information to a
given transaction. With enough detail, they can relay enough information
to cover many cases.

Fortunately, both detailed debugging and header value accumulation can
be done in the same code so we do not have to pick one over the other.

I recommend a two-prong approach to solve the second part of the
problem. Both (A) and (B) below should be applied only to the master
transaction matching the "triage caching" directive described above:

2A. Go through caching code and enable informative debugging of each
decision. Use a new debugging section so that the admin can control
output verbosity. Unlike the existing sections, this new debugging
section will only apply to matching transactions, not "source code
files". I would give it a name (e.g., "CachingTriage") instead of a number:

    debug_options ALL,1 CachingTriage,9 AclTriage,5

2B. Go through caching code and collect a list of primary decisions in
the form of a list of enumerated values or a list of key=value pairs.
Store that list in the master transaction object. Return that list in
the X-Cache-Triage response header.

Again, both (2A) and (2B) should only have an effect for master
transactions that matched the "triage caching" directive described in
Section 1.


> I know that the best practical way to do that is to add this as a squid
> feature, but since I do not like to work with C++ and since it is a
> complex task to learn from 0(my brain have some "ram" cache only and a
> good sleep many times just restarts the cache) I will prefer to write an
> ICAP service that does that.

ICAP and eCAP services do not get enough information to triage most
caching problems. IMO, to be generally useful, this should be done in Squid.


HTH,

Alex.