couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Bisbee <...@sbisbee.com>
Subject Re: Surprisingly high CPU load
Date Wed, 30 Mar 2011 17:17:22 GMT
Along the lines of client side caching, check out Sag. Currently uses ETags to
cache queries and docs in memory or disk with more storage mechanisms coming
soon.

http://www.saggingcouch.com
https://github.com/sbisbee/sag/blob/master/src/SagCache.php

Cheers,

--
Sam Bisbee
www.sbisbee.com

On Wed, Mar 30, 2011 at 09:55:12AM -0700, kowsik 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."
> >>
> >


Mime
View raw message