Re: [squid-users] Squid vs caching products like memcached

Great answer, thanks!

How does Squid's page caching ability work in terms of caching pages (as
though they are static) but that were generated dynamically?

For example, Amazon.com's homepage is dynamic but not generated dynamically
on each request for that page; rather, I assume they set it to be cached
anytime a request for that page comes in, with some sort of expiration
policy (e.g. only dynamically generate the homepage once an hour, then serve
that cached static page for the rest of that hour).

I really hope Squid makes such a configuration possible and easy.

Thanks.

Sean A. Walberg wrote:
>
> On 5/16/07, lightbulb432 <veerukrishnan@hotmail.com> wrote:
>
>> What's the difference between the reverse proxying features of Squid and
>> a
>> caching product like memcached?
>
> Memcached is a distributed, in memory, hash table with a network
> interface. Most often you stuff the results of expensive queries
> (database, computations, XML processing) into memcached so that
> multiple nodes can get the data without having to do the expensive
> query.
>
> Squid as a reverse proxy caches http objects -- pages, css,
> javascript, images, etc. You use squid to offload entire requests to
> your web server.
>
> As an example at b5media we front our web farm with Squid, but only
> cache images, javascript, and CSS. WordPress and Squid don't play
> well together because WordPress doesn't send out proper headers for
> Squid to use, so we don't cache pages.
>
> Beside taking hits off the web server, Squid is also good at spoon
> feeding slow clients. Previously a slow client keeps an expensive
> Apache slot tied up, now Squid takes that data from Apache and feeds
> the client -- squid is more efficient at this task than Apache.
>
> On the WordPress backend we store a lot of internal stuff in
> memcached. We have some internal code that uses a REST API that
> figures out what blog goes in which channel. Rather than make a
> handful of REST calls on every page view, which incurs latency for the
> web hit and CPU for the XML processing, we check memcached to see if
> the PHP object exists. If we get a memcached cache hit we've just
> saved ourselves a lot of time. If we get a miss, we make the API
> calls and stuff the PHP object back into memcached for the next
> person.
>
> I look at the caching within a LAMP application as a multilevel thing.
> We cache the http objects we can with squid. If we have to generate
> a page we cache what we can in memcached, just like we cache compiled
> PHP scripts in an opcode cache. If we have to hit the database we use
> MySQL query caching at that layer.
>
> It's not a one-or-the-other type of thing, these are two tools that
> are clearly the best at what they do, and can (should?) be used
> together as part of a good architecture.
>
> Sean
>
> --
> Sean Walberg <sean@ertw.com> http://ertw.com/
>
>

-- 
View this message in context: http://www.nabble.com/Squid-vs-caching-products-like-memcached-tf3765217.html#a10646669
Sent from the Squid - Users mailing list archive at Nabble.com.