Search squid archive

Re: Cacheing in the cloud

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 08 Nov 2011 08:02:29 -0600, David Brown wrote:
Hello, with all of the SaaS, PaaS and the like running on clouds
everywhere with packaged deployments that can't be tinkered with where
does Squid and cacheing come into the game?

In the "other" category AFAIK. (My knowledge of cloud details is low, so this may be so much hot air YHBW).

Depends on what you call "cloud", though.

If you are talking about VM style stuff where things float around between CPUs and physical machines. the cloud is done at the individual packet level. Squid is not even close to relevant at that level.

If you are talking about the SaaS side of clouds. Where services use AJAX / XHR / RESTful HTTP for APIs and interactions. Squid is one of the engines that can be used to move traffic around and provide scalable capacity. Integrating with ESI and ICAP services to provide pluggable capabilities. We are adding the real-time controls to integrate it better with the new shiny toys and management systems, so the abilities are both a bit clunky in older Squid and flexible in feature support as the releases get more recent.

If you mean something else, ... um. !?


Does squid run in these types of environments?

It runs usually as the foundation software for scaling out HTTP based SaaS systems, but can also run as a VM on top of the other types of cloud.

IIRC there is an Amazon EC based "Squid device" floating around somewhere for use as an easily scaled CDN in that cloud.


If so, is the cacheing advantage realized the same as in traditional
stand-alone hardware?

If by "the same" you mean the same way. Yes.
Squid has not changed much in its storage criteria since clouds became popular again.


If by "the same" you means the same amount. Unknown, the cloud benefits/problems fade beside the variability in site designs.

For example, at the two extremes we have Wikipedia designed to be cache friendly and general visitor traffic scales to 100% (many TB per minute) with little change in the internal service resource usage. Whereas YouTube is designed to be cache unfriendly and can blow out even a clouds bandwidth capacity under the same type of popularity. AJAX, XHR and RESTful requests tends to be less cacheable by their dynamic nature. But not necessarily so. Getting the cache benefit out of them requires expertise which a lot of the current web-devs seem not to have or at least not to think about when building things quickly.

This is specific to the caching features though, others like load balancing and traffic handling are not affected.


I ran some searches @ squid-cache.org but I did not find any real good
reading on this subject.

IMO that is because cloud and the related terminology are just the new words for stuff Squid and other software have been doing for decades. The documentation has not caught up to the re-wording, or description of how the traditional proxy cluster and cloud concepts map together. Terms like "routing" I used above, in the Squid context it has nothing to do with BGP or packets, but maps easily to the cloud concept of channel management. Or caching, in the SaaS cloud is somewhat between an aggregating buffer and a data source.


PS: blog/whitepaper/ web articles welcome if anyone with more knowledge in both areas wants to try their hand at writing something up properly.

Amos



[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux