Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.132.242 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:content-transfer-encoding;
        b=peaYdzfNfqsUeTyNvVUtASqN3M78Ixavm+Wdy5YDp8M1AHclXppgb/3MSx4F9BmM9g
         BQbOB1yguOjv3Hc2pGwHucv1Vofh1HaPxqslDCm+agvAy45ddv3ZDtz0JPqj1ej28ntQ
         TBV1cvHPTqIsNcQeo7VZpdtnvcqXuIeF4SSNE=
MIME-Version: 1.0
In-Reply-To: <7736CE3C-A156-4166-A550-5A40CB9025CA@gmail.com>
References: <84F66023-030A-4669-B75C-3DCC92D71A78@yahoo.com>
	 <e2111bbb0902090823h43bcf918ge329916cd5e310e9@mail.gmail.com>
	 <A1BCBE02-893D-40EA-B242-A10292B4287F@gmail.com>
	 <e2111bbb0902090935m799be568j16f7e9324bb01ef2@mail.gmail.com>
	 <54602F24-6517-459F-98DB-1A934A98A3B8@gmail.com>
	 <D3A11D36-6555-4D32-8610-9425B222478C@gmail.com>
	 <8CC336DF-241D-4E79-960D-763E43D4B484@apache.org>
	 <EF4161F9-E211-439C-BCE5-219CE506EF43@gmail.com>
	 <e2111bbb0902091600v688130d5te47c8e5fd87bce3a@mail.gmail.com>
	 <7736CE3C-A156-4166-A550-5A40CB9025CA@gmail.com>
Date: Mon, 9 Feb 2009 19:41:04 -0500
Message-ID: <e2111bbb0902091641r8961f2dtc3457c160551ed93@mail.gmail.com>
Subject: Re: couchdb transactions changes
From: Paul Davis <paul.joseph.davis@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Mon, Feb 9, 2009 at 7:23 PM, Antony Blakey <antony.blakey@gmail.com> wrote:
>
> On 10/02/2009, at 10:30 AM, Paul Davis wrote:
>
>> Alas it is true, if you have a system that has operating
>> characteristics that involved a write load that far outweighs the read
>> load
>
> I don't think it has to far outweigh it, just exceed it. And in any case,
> that's assuming that there's a single reader. With replication you might
> have many readers doing duplicate reads, which means that the effective read
> rate w.r.t the write rate is divided by the number readers.
>
> For example consider that you have 100 replication readers. Each reader will
> advance at 1/100'th the rate of a single reader. So the write rate only has
> to be > 1% of the theoretical read rate to exceed the effective read
> rate/progress of the individual replicators.
>
> And that's ignoring the fact that the effective read rate for replication is
> dependent on bandwidth and connectivity e.g throughput is not the same as
> raw read rate in any case.
>

Actually, seeing as that file system reads would get cache hits 100%
of the time and your disk write throughput would be limited to 60.45%
coupled with the fact that a write rate is less than 1% of the
available bandwidth and if the moon is in it's third phase we can
definitively prove that hand waving about numbers proves nothing.

On the other hand if someone were to benchmark this then we could
discuss the reality of what sustainable read/write rates CouchDB can
handle. The reports I've heard about load leads me to believe that
your numbers are a bit off, but I couldn't tell you without repeatable
benchmarks.

HTH,
Paul Davis

> Antony Blakey
> -------------
> CTO, Linkuistics Pty Ltd
> Ph: 0438 840 787
>
> All that is required for evil to triumph is that good men do nothing.
>
>
>