Re: [squid-users] Using squid as a CDN like.

 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
Received on Wed Sep 21 2011 - 01:26:37 MDT