Jason Healy wrote:
I've been inspired by the recent discussions to set up my own 
multiple-instanace Squid box.  I've got it running with some real connections 
in a basic config, and I think I've got most of the general config issues 
worked out.

I have questions about some of the advanced tweaking and how it works with 
multiple instances, and I'm also looking for a general sanity check on my 
config...

We have 7 instances of Squid 2.7STABLE running on a single box right now.  2 are 
"frontend" (used by clients), and 5 are "backend" (parent peers to the 
frontends).

The frontend instances have all the ACLs, delay pools, and access logging.  
They are configured for memory-only caching (no storedir), and max out at 4GB 
process space.

The backend instances have small cache_mem and have the storedirs defined.  
They don't do any delay pools, ACLs or logging (unless I need debugging).

I'm wondering:

 - Do delay pools work properly if they're only on the frontend, or are they 
ignored if a peer handles the request for us?  I'm hoping they do, otherwise 
there's no good way to enforce consistent limits when spread across 5 backends.

Unless you specify "no-delay" on the cache_peer line, delay pools are active even to peers.

 - If I use a rewrite program, should I have it on just the frontends, just the 
backends, or all instances (I'm not sure how the rewrite affects peer requests)?

I'd suggest putting the url_rewrite_program on the front end as...

        Please note - the normal URL rewriter rewrites Squid's _destination_
        URL - ie, what it fetches. The Store URL rewriter rewrites Squid's
        _store_ URL - ie, what it uses to store and retrieve objects.

http://www.squid-cache.org/Doc/config/storeurl_rewrite_program/

 - Similarly, should I use storeurl_rewrite_program on the frontends, the backends, or 
all instances (I suspect it should be "all")?

If the requests made to the parents has been normalized by the url_rewrite_program, then you shouldn't need a storeurl_rewrite_program at all.

 - I'm using round-robin for the backend peer selection.  Should I switch to 
carp, or is that overkill when the instances are on the same physical box?  
What advantages does carp have?

CARP routes a given request to the same parent every time. Since cache can't be shared between instances (on the same server or not) this can aid caching efficiency.

Thanks,

Jason

--
Jason Healy    |    [email protected]    |   http://www.logn.net/

Chris

Reply via email to