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.
