Re: Question about Proxy with high load and big banned sites list

From: Clifton Royston <[email protected]>
Date: Thu, 19 Aug 1999 09:54:19 -1000 (HST)

Luigi Giacobbe writes:
> The Proxies 3 and 4 act like caching, there are no redirector process there.
> Clients only connect to Proxies 3 and 4.
> If the requested object is not found then Proxies 3 and 4 ask to Proxies 1
> and 2.
> Proxies 1 and 2 acts as filter. There are redirector process on them.
> Proxies 3 and 4 have a big cache (18 GB each) and proxies 1 and 2 a small (3
> GB each).
> With this design, Filter should be support a minder load.
> First results arent bad but ... there are problems with CGI (poor
> performance).
> Like told in "the Tutorial on Configuring Hierarchical Squid Caches", Parent
> should NOT handle CGI and other non-cachable requests.

I believe that is mainly to avoid the "wasted motion" of connecting to
two caches for something that won't be retrievable. You would still
use the never_direct option in this case or other cases similar to
this, as where Squid *has* to go through a firewall proxy.

> But if I told the cache Proxies 3 and 4 to take directly the CGI requests,
> there is a potential hole in the filter policy.
> Any idea , suggestion ?

Off the cuff, I have three alternative suggestions to make this work
better:

1) Don't use Squid or any caching proxy on #1 and #2, just use a filter
   proxy or redirector. Let all the caching happen in #3 and #4,
   because you will get no benefit if the caches on #1 and #2 is
   smaller than #3 and #4. (All the requests coming there have "aged
   out" or been swapped out of the larger cache, and therefore are long
   gone from the smaller one.) This should reduce the delays on going
   through the second proxy, and allow you to go on forcing all
   requests through them.

2) "Flip" the positions of the proxies, so that clients connect
   directly to #1 and #2 which validate them with a proxy filter and/or
   redirector (and no cache or minimal cache); then #1 and #2 connect
   to #3 or #4 if the content requested (now verified to be OK) is
   cacheable, or go direct if it's not, e.g. for CGI.

3) Implement the redirector process directly on #3 and #4, and
   re-deploy #1 and #2 somewhere else.

I think (2) or (3) probably would work out better.
  -- Clifton

-- 
 Clifton Royston  --  LavaNet Systems Architect --  cliftonr@lava.net
        "An absolute monarch would be absolutely wise and good.  
           But no man is strong enough to have no interest.  
             Therefore the best king would be Pure Chance.  
              It is Pure Chance that rules the Universe; 
          therefore, and only therefore, life is good." - AC
Received on Thu Aug 19 1999 - 13:35:00 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:48:04 MST