Re: [squid-users] Re: in-transit objects and more new requests for them

On 12/14/2013 08:00 AM, mohamad pen wrote:

> I did some experiments on on both squid 2.7 and squid HEAD.bazaar
> (from launch pad)

I assume that you mean the unofficial collapsed-fwd branch from
launchpad (the HEAD.bazaar label is confusing because the official trunk
code is using the same one -- we should have changed the branch label to
avoid this confusion; sorry).

I cannot help you with Squid v2.7 so I will focus on the collapsed-fwd
case. Here is the relevant documentation from squid.conf.documented:

> TAG: collapsed_forwarding (on|off)
> This option controls whether Squid is allowed to merge multiple
> potentially cachable requests for the same URI before Squid knows
> whether the response is going to be cachable.
>
> This feature is disabled by default: Enabling collapsed forwarding
> needlessly delays forwarding requests that look cachable (when they are
> collapsed) but then need to be forwarded individually anyway because
> they end up being for uncachable content. However, in some cases, such
> as accelleration of highly cachable content with periodic or groupped
> expiration times, the gains from collapsing [large volumes of
> simultenous refresh requests] outweigh losses from such delays.
> Default:
> collapsed_forwarding off

Please use the generated squid.conf.documented when testing the
unofficial collapsed-fwd branch.

> which both have claimed to support collapsed
> forwarding (ability to create on connection to origin for every
> in-transit instances of a url)

Please note that the collapsed-fwd branch code only tries to collapse
requests for potentially cachable responses. It does not collapse
requests if it is clear that the response is not going to be cached (due
to request headers or due to disabled caching, for example).

There are other pre-conditions. Moreover, the code has been primarily
tested with Rock and memory caches. I do not recall whether it works
with UFS-based caches.

To start triaging this, I recommend the following steps:

1. Enable collapsed_forwarding in squid.conf. Disable disk caching. Do
not use SMP. The latter two features can be enabled (one at at time!)
later in step 4A.

2. Send two concurrent requests for a test URL. Collapsed forwarding
works only when the second concurrent request is received after the
headers of the first concurrent request has been parsed but before the
the response headers corresponding to the first request have been
parsed. Thus, use a small time gap between the two requests and, if you
can, delay the server response to make sure the two requests can be
collapsed.

3. Look at the two responses, is one of them a HIT? If yes, you may have
succeeded and may go to step 4A (to know for sure that this is not a
regular HIT, you have to delay the server response or study low-level
request timings/logs). If not, go to step 4B.

after success in 3:

4A. Enable disk caching or SMP (one at a time) if you need those
features. Purge cache or use a different test URL. Go to step #2. If the
test fails after this, you may be able to blame the specific single
feature you enabled and not collapsed forwarding "in general".

after failure in 3:

4B. Send a single request for the same test URL and look at the
response. Is it a HIT? If yes, there may be a problem to triage further.
If not, use a different test URL and go back to step 2 because your test
URL is not producing hits.

HTH,

Alex.
Received on Mon Dec 16 2013 - 18:21:38 MST