On Tue, 20 Sep 2011 17:22:05 +0200 (CEST), Jean-luc Tresset wrote:
Hi and thanks a lot for your answer.
It confirms what I thought :o(
And unfortunately the squids won't be on the same lan at all.
In so far as I have a lot of little data chunks to propagate, I'm
going to think about an "intelligent" way to pull them to the distant
squids.
The problems is only in server-initiated "push" of content to the
Squid. Change the thinking to "pull" (client-initiated requests) and it
becomes trivially easy. HTTP is designed from the ground up with a
"pull" architecture. All you need is to determine how much space to
allocate for cache storage and Squid does all the heavy lifting out of
the box.
NP: "pre-caching" is the term to lookup for the various tools and
methods involved.
Whether you care much about "hot" vs "cold" caches is something to
consider. The difference being that cold caches have a spike in
bandwidth when the proxy first starts up and needs to fetch everything
in, decreasing exponentially as it stores things. The smaller the
objects handled the faster they are made available for re-use, and the
faster the spike decays. So the smaller the objects the less this
problem actually matters. Although it is relative to the bandwidth
available on each link so is somewhat installation specific to decide
on.
The fine details are all up to the server and what headers it sends for
Cache-Control and expiry information when producing an object. For
things which do not matter much on update timing you can set flexible
timing controls, and for things which need tight update propagation send
"Cache-Control: must-revalidate". BUT, ensure that the server is not
doing a lot of CPU-intensive tasks to handle the
modification/revalidation checks (If-* headers) from Squid.
This documentation on designing websites to work well with caching may
be of some use:
http://www.mnot.net/cache_docs/
On the Squid side, we have ongoing HTTP/1.1 compliance improvements
since 2.6 Series. The latest releases you can work with the better
service Squid will be able to provide you and your customers.
Amos
Best regards,
JLT
----- Mail original -----
El sep 20, 2011 8:03 a.m., "Jean-luc Tresset" escribió:
>
> Hi !
>
> I'm currently thinking about the best way to build a little CDN
like
> system based on squid. I've already understood how to manage the
DNS
> problems, but I wonder what is the best way to push the same
content
> at the "same time" on different server. Is it possible with squid
?
>
> Regards,
> JLT
Hi Jean,
Well as you don't give too much informatio, I guess you want to have
many squids distributed and depending somekind of dns load balancing
squid1 or squidN shall answer. I also asume you are taling in
reverse
proxy schema.
Well, first bad news is that it is kind imposible to push objects in
cache. So, if you want to warm it, you shall do a script to pull
objects throug squid until they get in.
The good news is that there is a way to workarround your request.
You
may use peers squid with multicast capabilitie (multicast is
optional,
only if all squids are in same lan). Use your peers with a ttl=5, it
is fater to ask a peear than a http parent.
Well, multicast is also possible over the WAN if you have transit and
carrier support between the Squid. In IPv4 there appears to have been a
lot of reluctance, so it is usually not available. In IPv6 multicast is
mandatory, so things should improve in the coming years.
Amos
