On 5/16/07, lightbulb432 <veerukrishnan@xxxxxxxxxxx> 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@xxxxxxxx> http://ertw.com/
