Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of sean.copenhaver@gmail.com
 designates 209.85.212.52 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
         :content-type;
        b=l9ZBGQ667r2QyNetL0n9ryiIShkaKKG7Sq3xg47fdPwXIFZhgbd3Kvz94vIqffWDrm
         ve9xi8TzRU4Ypmi29jMjXfClbsfy5IijJBNECBnq2l4Ep16dCBX5Kd12vuu8HtY7xbQj
         pb4tqPhoswkEBS8iIDb/rPcZ53+tx1RNqQYWQ=
MIME-Version: 1.0
In-Reply-To: <AANLkTimBXe3nBmbFLUsqLE0=_sqjKKES06LPBTnMiteB@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>
	<AANLkTimBXe3nBmbFLUsqLE0=_sqjKKES06LPBTnMiteB@mail.gmail.com>
Date: Wed, 30 Mar 2011 13:07:52 -0400
Message-ID: <AANLkTimCES6fA3eq+6Y_e=RnvR6aXRFVCS2ug+4bmDM-@mail.gmail.com>
Subject: Re: Surprisingly high CPU load
From: Sean Copenhaver <sean.copenhaver@gmail.com>
To: user@couchdb.apache.org
Content-Type: multipart/alternative; boundary=20cf3071cbd696f8b7049fb63706

--20cf3071cbd696f8b7049fb63706
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I would imagine the merging of memcache and couchdb (well couchbase but
hopefully contributed back) could result in things like this.

On Wed, Mar 30, 2011 at 12:55 PM, kowsik <kowsik@gmail.com> wrote:

> 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>
> wrote:
> >>>
> >>> 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.
> >>  Unreasonable men adapt the world to themselves.
> >>  That's why all progress depends on unreasonable men."
> >>
> >
>


--=20
=93The limits of language are the limits of one's world. =93 -Ludwig von
Wittgenstein

--20cf3071cbd696f8b7049fb63706--