Using Varnish to accelerate CouchDB

[Karel Minařík]

Hello,

> I haven't really ever touched Couch, but from what I overheard I think
> you can embed custom code into the database, meaning it should not be
> to hard to wactually have the database call out to Varnish and
> invalidate the content itself.

invalidating the cache could be done most conveniently via the  
_changes feed or via the "update_notification" mechanism [http://wiki.apache.org/couchdb/Regenerating_views_on_update 
, probably. Since not only single documents, but also aggregated view  
results or fulltext queries would get cached, it wouldn't be exactly  
trivial to expire everything. "There are two hard things in computer  
science ..."

I am sorry to ask the same dumb questions over and over, but does it  
mean, that Varnish does not work in ETags, ie. does not support  
"Validation" type of caching as opposed to "Expiration" caching in the  
sense of Ryan Tomayko's article [http://tomayko.com/writings/things-caches-do 
] ?

I am well aware that "dumb caching" based on ETags would not  
accelerate anything when it would make 1 "check" request to backend  
for every 1 request to the cache. It was my impression that Varnish  
could be configured to eg. deal with concurrent 100 requests to some  
resource and "accumulate" them, eg. not send them all to the backend.

The reason I am asking is that in a backend such as a Ruby On Rails,  
computing an ETag could be much cheaper then computing and returning  
whole response. So, once again and for the last time, sorry :) --  
there is no way to use Varnish like this? Only time-based (Expires,  
Last-Modified, etc) caching is possible?

> You might have more luck asking on the Couch list, though.

Yes, definitely, I'll ask there for any experience. There seem to be  
rather little information available -- while I am quite certain that  
lots of people is Using Varnish to accelerate Couch.

Thanks!,

Karel