Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of kowsik@gmail.com designates
 209.85.210.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=MVA7sEyICqyVo42sV6W7THbNj1XrXINdkIz3bNkdeLRR5lejtIrdt4FM5UO+cdki9G
         shAFyMH4AAwY9YZS1wpSOdk7LMvp7o4rDquA7aembzGl39BaxIvfLq+X+t+zXNXLy1Wv
         T3Oy1XFh07PnLn8riTciDlGvyqoOEd66RSDfQ=
MIME-Version: 1.0
In-Reply-To: <AANLkTinYo7s1UobOwLyuzJr4p89JADybuseRjNrpHaO-@mail.gmail.com>
References: <95002D3F-8F13-4977-A640-446AF2745DBD@adesso.de>
	<1301469307.21215.199.camel@meerkat.green.sophos>
	<AANLkTinBwgK8XdJ56Gmi-S0cv2k34RFyU+42jBndfNjZ@mail.gmail.com>
	<AANLkTinYo7s1UobOwLyuzJr4p89JADybuseRjNrpHaO-@mail.gmail.com>
Date: Wed, 30 Mar 2011 09:55:12 -0700
Message-ID: <AANLkTimBXe3nBmbFLUsqLE0=_sqjKKES06LPBTnMiteB@mail.gmail.com>
Subject: Re: Surprisingly high CPU load
From: kowsik <kowsik@gmail.com>
To: user@couchdb.apache.org
Cc: bryan rasmussen <rasmussen.bryan@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

In the end, RAM *always* wins. Use fragment caching (rails/sinatra) or
memcached/redis before you bother Couch. That said, I'm seeing direct
doc fetches from CouchDB in the low 10's of milliseconds running on an
EC2 large instance.

This could be an interesting "feature" in CouchDB. Since it "knows"
about the changes and revisions, it could cache the the latest
revisions of a certain number of documents (memory threshold of sorts)
in memory and return it without disk seeks.

K.
---
http://blitz.io
http://twitter.com/pcapr

On Wed, Mar 30, 2011 at 3:10 AM, bryan rasmussen
<rasmussen.bryan@gmail.com> wrote:
> How do people deal with this issue in production environments? Just
> adding more CPUs? Any optimizations that one commonly sees?
>
> Thanks,
> Bryan Rasmussen
>
> On Wed, Mar 30, 2011 at 11:54 AM, Filipe David Manana
> <fdmanana@apache.org> wrote:
>> On Wed, Mar 30, 2011 at 8:15 AM, Paul Hirst <paul.hirst@sophos.com> wrot=
e:
>>>
>>> You might find this an interesting read
>>> https://issues.apache.org/jira/browse/COUCHDB-1092
>>>
>>> The performance improvements discussed in that bug sound extremely
>>> appealing but the discussion has gone quiet which is a great shame. I'm
>>> still hoping something comes of it.
>>
>> It probably will, the only drawback identified in the discussion of
>> that ticket is not that hard to fix.
>>
>> Also, before moving that one forward, I've been trying several other
>> performance and disk saving approaches and measure the gains of each
>> one. In the end we'll see. Maybe that one gets dropped and something
>> better or equivalent comes out.
>>
>>>
>>>
>>>
>>> Sophos Limited, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP=
, United Kingdom.
>>> Company Reg No 2096520. VAT Reg No GB 991 2418 08.
>>>
>>
>>
>>
>> --
>> Filipe David Manana,
>> fdmanana@gmail.com, fdmanana@apache.org
>>
>> "Reasonable men adapt themselves to the world.
>> =C2=A0Unreasonable men adapt the world to themselves.
>> =C2=A0That's why all progress depends on unreasonable men."
>>
>