Using Varnish to accelerate CouchDB
karel.minarik at gmail.com
Sun Nov 7 10:00:52 CET 2010
> 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
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.
More information about the varnish-misc