Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-Id: <84D516F0-BCEF-4730-925B-D5C27E1A591D@apache.org>
From: Jan Lehnardt <jan@apache.org>
To: user@couchdb.apache.org
In-Reply-To: <b66ddc900903140432y8def6bbndc806f6853d666b1@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Use couchdb as the data store for real-time chat room
Date: Sat, 14 Mar 2009 13:10:16 +0100
References: <b66ddc900903140320u5bdbf3ffoaed76f332899c45e@mail.gmail.com>
 <82964F3E-9C96-4784-8280-01B4155E999D@jasondavies.com>
 <b66ddc900903140432y8def6bbndc806f6853d666b1@mail.gmail.com>


On 14 Mar 2009, at 12:32, howard chen wrote:

> Hi,
>
> On Sat, Mar 14, 2009 at 6:57 PM, Jason Davies  
> <jason@jasondavies.com> wrote:
>> CouchDB gives you a lot more for
>> free (flexible schema, replication and in general designed for high
>> scalability) so I would recommend giving it a try.
>>
>
> Sure will have a try later on.
>
>
>>> 2. Is Memcached useless if I am using couchdb?
>>
>> I'm guessing memcached would still be useful as a caching layer to  
>> squeeze
>> that extra bit of speed if you have the RAM, but maybe someone else  
>> can
>> speak from experience.
>>
>
> The reason I ask is since couchdb output JSON, so ideal case is to let
> users contact couchdb directly in term of scalability. If adding a
> cache layer using Memcached which eat data from HTTP response seems
> too much overhead involved as Memcached is a also key-value store.
>
> Don't know if couchdb has some kind of query cache and how to tune?
> Oh..maybe I should use squid?

CouchDB uses the filesystem buffer as a cache. CouchDB's b-tree storage
is a fairly thin layer on top of the filesystem and you should get  
decent caching
characteristics out of the box. Of course, no requests are better than  
cached
requests. View results come with HTTP ETags that allow you to find out  
if a
client would need to re-fetch an item.

Squid* and Varnish do file caching as well where there might be faster  
than
CouchDB but probably not magnitudes. A memory-based HTTP cache might
help you (nginx & memcache), but I think you can go a long way with pure
CouchDB and HTTP caching alone.

(* There is an anecdote on the web where Squid tries to outsmart the  
filesystem
buffer cache and ends up doing two disk-to-memory operations where one
would do, I can't seem to find the reference right now).

Cheers
Jan
--