From dev-return-9362-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Fri Mar 26 21:24:45 2010
Return-Path:
Delivered-To: apmail-couchdb-dev-archive@www.apache.org
Received: (qmail 88339 invoked from network); 26 Mar 2010 21:24:45 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
by 140.211.11.9 with SMTP; 26 Mar 2010 21:24:45 -0000
Received: (qmail 57905 invoked by uid 500); 26 Mar 2010 21:24:45 -0000
Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org
Received: (qmail 57861 invoked by uid 500); 26 Mar 2010 21:24:45 -0000
Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@couchdb.apache.org
Delivered-To: mailing list dev@couchdb.apache.org
Received: (qmail 57853 invoked by uid 99); 26 Mar 2010 21:24:44 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 26 Mar 2010 21:24:44 +0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of adam.kocoloski@gmail.com designates 209.85.219.221 as permitted sender)
Received: from [209.85.219.221] (HELO mail-ew0-f221.google.com) (209.85.219.221)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 26 Mar 2010 21:24:35 +0000
Received: by ewy21 with SMTP id 21so2333002ewy.5
for ; Fri, 26 Mar 2010 14:24:15 -0700 (PDT)
Received: by 10.213.50.84 with SMTP id y20mr886137ebf.71.1269638652340;
Fri, 26 Mar 2010 14:24:12 -0700 (PDT)
Received: from [10.2.51.97] ([12.236.246.2])
by mx.google.com with ESMTPS id 15sm905076ewy.8.2010.03.26.14.24.09
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Fri, 26 Mar 2010 14:24:10 -0700 (PDT)
Subject: Re: Performance Regression for view generation in 0.11
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Adam Kocoloski
In-Reply-To:
Date: Fri, 26 Mar 2010 14:24:06 -0700
Cc: Henrik Thostrup Jensen
Content-Transfer-Encoding: quoted-printable
Message-Id: <29383F0A-1895-49EC-AF9B-1E9E7181B5CD@apache.org>
References:
To: dev@couchdb.apache.org
X-Mailer: Apple Mail (2.1077)
X-Virus-Checked: Checked by ClamAV on apache.org
On Mar 15, 2010, at 6:10 AM, Henrik Thostrup Jensen wrote:
> Hi
>=20
> On 13 March 2010 20:44, Benoit Chesneau wrote:
>=20
>> delayed_commits =3D true ; set this to false to ensure an fsync =
before
>> 201 Created is returned
>> batch_save_size =3D 1000 ; number of docs at which to save a batch
>> batch_save_interval =3D 1000 ; milliseconds after which to save =
batches
>>=20
>> are the settings you may want to change in ini.
>=20
> This appears to work in 0.10, but is (as far as I can tell) ignored in
> 0.11, due to the changed view collection architecture, which relies on
> work queues, which have statically defined sizes (see line 42-43 in
> couch_view_updater.erl).
>=20
> I have a synthetic benchmark for view generation over 70K documents.
> In stock CouchDB 0.10, the view will be checkpointed about 15-17
> times. Around 9 times with the batch_save_size and batch_save_interval
> set to 10000. CouchDB 0.11 on the other hand performs a whopping
> 108/109 checkpoints of the view. Due to shadow B-trees this generates
> significantly larger view files (2-3x much) and more time is spend
> writing to disk. Generating the view takes roughly twice as long in
> 0.11 as it does in 0.10.
>=20
> I've tracked down the problem to the new view generation architecture;
> particularly the small sizes of the work queues defined in
> couch_view_updater.erl. The attached patch decreases the number of
> checkpoints to around 15, and makes view generation slightly faster
> than 0.10. It basically increases the size of the write queue.
> Inserting a 500 ms sleep in do_writes increased the performance a bit
> more, but that is not a nice or right solution.
>=20
> I suspect the patch is not "the completely right solution (tm)", as a
> lot checkpoints are performed initially whereafter it backs off and
> starts to take longer time/revisions between the checkpoints. I
> suspect that the code is just writing repeatedly and as writes start
> to take longer time, more revisions are added per checkpoint. Though I
> am not really sure of this.
>=20
> Still, it is a 2 line patch, and it significantly increases view
> generation performance. I'd very much like to see this in 0.11, to
> avoid a rather large performance regression between 0.10 and 0.11. If
> 0.11 comes out as it is, we would either have to stick with 0.10 or
> build our own patched 0.11.
>=20
> --=20
> - Henrik
>
Henrik, thanks for this cogent and detailed analysis. I was aware that =
the 0.11 work queues introduced significantly more checkpoints and thus =
larger uncompacted view index files in the normal case where writes to =
the view indices are fast. I was not aware that this slowed down =
overall view generation time; I had always sort of assumed that the =
queues would make optimal use of resources. How many cores do you have =
on your benchmark rig?
It's probably too late to add this simple patch to 0.11, but I'm sure =
something like it will be in 1.0 (which should follow shortly on the =
heels of 0.11). Best,
Adam=