incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "[mRg]" <emar...@googlemail.com>
Subject Re: CouchDB for production
Date Tue, 18 Aug 2009 10:55:18 GMT
Thanks Brian, I shall power up my netbook now :D
The info should be pretty much be read-only so I'll hoik up the RAM :)

Paul: I think the EC2 idea is great .. hadn't thought of that
.. definitely worth exploring to get some baselines.

2009/8/18 Brian Candler <B.Candler@pobox.com>

> On Tue, Aug 18, 2009 at 08:52:17AM +0100, [mRg] wrote:
> > ? As an idea of scale the site is expected to handle 8,000,000 hits per
> > month (approx 250,000 per day) and while Couch isnt providing all of the
> > site functionality it is supporting the tagging elements which is a major
> > part of the site.
>
> 250,000 hits per day is an average of less than 3 hits per second. You
> could
> probably run it on a netbook :-)
>
> However you should consider how many updates and view updates are taking
> place, and include this in your load-testing.
>
> That is: if this is all just read activity, it will be handled efficiently
> by the btree indexes, especially if you have enough RAM for these to remain
> cached.
>
> But if there are lots of updates taking place, then there will be lots of
> view-building activity going on too. The worst-case scenario here is if you
> have lots of DBs (e.g. one DB per user); lots of updates occur to a user's
> DB while they are away; and then they come back and hit a view. This will
> cause all the views in that design doc to be updated from some point in the
> past until now, which would cause a large disk and CPU spike which could
> cause performance degradation for other users.
>
> In my experience, this is one aspect which Linux doesn't handle well: do
> something which involves lots of disk writes (even just a big cp or tar)
> and
> interactive performance for the rest of the system suffers badly. Back when
> I was using FreeBSD in production it seemed to be better in that regard,
> but
> I'm not sure if that's still true today.
>
> Regards,
>
> Brian.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message