Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jan@prima.de designates
 83.97.50.139 as permitted sender)
Message-Id: <80FA086F-73E6-4B06-8A50-1EB8A39CE0FC@prima.de>
From: Jan Lehnardt <jan@prima.de>
To: couchdb-user@incubator.apache.org
In-Reply-To: <000401c89268$10abd590$9e00a8c0@stade.topconcepts.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: using couchdb as caching system
Date: Thu, 3 Apr 2008 23:36:25 +0200
References: <001901c8918f$806c2120$9e00a8c0@stade.topconcepts.net>
 <E9958A61-4134-4401-BF31-1FD70B071325@apache.org>
 <000401c89268$10abd590$9e00a8c0@stade.topconcepts.net>

Heya Sven,
On Mar 30, 2008, at 15:15, Sven Tietje wrote:
>
>>> do you have experience in using couchdb as caching-system? we are
>>> thinking about storing generated html-documents in couchdb. your
>>> experience?
>>
>> No experience so far, but why not use the filesystem? :-)
>
> hi jan,
>
> it`s a distributed system and only files like images, pdf are handled
> through the filesystem. caching should be done by a single independent
> server. another point is that we cache parts of a html-page -> some  
> parts
> are generated dynamically. doing a request to the file-system for  
> each part
> is not performant :-)
>
> i`d like to get all cached parts with one request. eg: html-page / 
> blub.html
> ist called. now, there can be 2 cases:
>
> 1. total page has been cached
> 2. only parts have been cached
>
> i want to get all information with one request. storing it in  
> couchdb would
> make it possible to store it all in one document - correct?
> {
> 	full_html: null or html,
> 	parts: {
> 			....
> 	}
> }
>
> of course, i can store json in a file in the filesystem, but will i  
> be able
> to scale my caching-system?

Okay, your reasons to use CouchDB seem, erm, reasonable :)
The only problem at the moment is that CouchDB does not
perform any internal caching. So all reads and writes go directly
through disk. While a caching layer is planned and relatively
easy to embed, it has not been done yet. So at the moment you
would not benefit from a lot of actual caching. In the future: Sure.
When: I do not know.

You could put a reverse HTTP proxy in front of CouchDB for the
actual caching in the meantime, though and remove it, when
CouchDB is fast enough for your needs.

Cheers
Jan
--