: Because one of my backend is Amazon S3 and I can't set up
: Cache-Control on it. So I looking for different solution how to change
: this header field (squid). I want the objects to be cache as long as
: possible on the clients web-browser side (1 year).
I've never used s3, but this
: Couldn't the same thing be done with ACLs? (deny icp/htcp from
: localhost)
: The problem is multi-stage loops: proxyA-proxyB-proxyA which only shows
: up in the two headers.
:
: The first-degree example I list above can be solved by ACL in icp_access,
: but when you go another level out
: Apache/PHP = Send out expire = A + 10 years = Squid = Send out expire = A
+ 0
...
: So until my program purege cache from Squid, it will keep cache in
: Squid as long as possible; on the other hand, client will request the
: latest content from Squid everytime.
if your goal really is
I'm trying to test out the behavior of various options with sibling
peering, and noticing something that seems really strange in how squid
responds to ICP query when it has the object in it's cache, but the TTL is
under 30 seconds...
squidA and squidB are configured as siblings of each
: For a bit of leverage; every time the config changes squid needs to be
: reconfigured, which causes a short outage.
:
: I've been thinking about it, and the multiple-IPs for a cache_peer might
: work when a DNS name is entered as first parameter of cache_peer. But only
: the IPs detected at
: Another solution could be to use a multi-level CARP config, which incidentally
: scales far better horizontally than ICP/HTCP, as it eliminates the iterative
: sideways queries altogether by hashing URLs to parent cache_peers. In this
...
: different IP or TCP port that actually does
: What would be really nice is a command line option and a bit of code
: in the cache peer setup that recognizes own IP and ignores the entry,
: to make this problem just all go away...
That would be awesome, but if i'm understanding you correctly it would
only address the talking to myself
Background Information...
My company currently runs several clusters of application servers behind
load balancers, which are each in turn sitting behind a cluster of squid
machines configured as accelerators. each squid cluster is then sitting
behind a load balancer that is hit by our
: The DNS way would indeed be nice. It's not possible in current Squid
: however, if anyone is able to sponsor some work it might be doable.
If i can demonstrate enough advantages in getting peering to work i might
just be able to convince someone to think about doing that ... but that
also
: Ok, it has come to my attention that /cache only grwos when I run a
: report
...
: cache_dir ufs /cache 50 256 256
...if i can start by asking a silly question: i assume your cache is
not yet at the maximum size?
The next silly question: have you done any analysis of the squid logs
: I have squid configured as a transparent proxy in front of application server
: (ApS). Data generated by ApS gets updated infrequently and sometimes ApS gets
: slow doing it's internal housecleaning. What I want to do is for Squid
: to fudge response times a bit by timing out connections to
: So it kind of seems like i'm out of luck right? my only option being to
: try 2.HEAD which *may* have the behavior i'm describing.
:
: Its part and parcel with free software. We can be paid to test it in a lab
: and give you a certain answer if you'd like. :)
Oh, believe me -- I know the
sorry for the late reply, i was seriously sick last week and basically
dead to the world...
: The problem I'm running into is figuring out a way to get the analogous
: behavior when the origin server is up but taking too long to respond
: to the validation requests. Ideally (in my mind)
: Tip: fwdReforwardableStatus() I think is the function which implements
: the behaviour you're seeing. That and fwdCheckRetry.
My C Fu isn't strong enough for me to feel confident that I would even
know what to look for if I started digging into the code ... I mainly just
wanted to clarify
Greetings,
I'm trying to make sense of some behavior I'm observing related to the
read_timeout.
I'm dealing with an accelerator setup, where I'd rather return stale
content (or an error) then wait for the origin server to return fresh
content if it is taking too long to respond.
I was hoping
15 matches
Mail list logo
