Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Message-ID: <11491556.47411273860045423.JavaMail.jira@thor>
Date: Fri, 14 May 2010 14:00:45 -0400 (EDT)
From: "Adam Kocoloski (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Subject: [jira] Commented: (COUCHDB-762) Faster implementation of
 couch_file:pread_iolist
In-Reply-To: <26452905.43701273850501727.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/COUCHDB-762?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D128=
67602#action_12867602 ]=20

Adam Kocoloski commented on COUCHDB-762:
----------------------------------------

Just a comment about the breakdown of time spent reading a term.  We're loo=
king at median response times of 70 =C2=B5s to read a 10K binary.  I think =
this is roughly distributed as

crypto:md5 - 30 =C2=B5s
pread()*2 - 20 =C2=B5s
everything else - =C2=B5s

> Faster implementation of couch_file:pread_iolist
> ------------------------------------------------
>
>                 Key: COUCHDB-762
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-762
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: Database Core
>    Affects Versions: 0.11
>         Environment: any
>            Reporter: Adam Kocoloski
>            Priority: Minor
>             Fix For: 1.1
>
>         Attachments: 762-pread_iolist-v2.patch, 762-pread_iolist.patch, p=
atch-to-reproduce-benchmarks.txt, pread_iolist_bench.erl, pread_iolist_resu=
lts.txt
>
>
> couch_file's pread_iolist function is used every time we read anything fr=
om disk.  It makes 2-3 gen_server calls to the couch_file process to do its=
 work.
> This patch moves the work done by the read_raw_iolist function into the g=
en_server itself and adds a pread_iolist handler.  This means that one gen_=
server call is sufficient in every case.
> Here are some benchmarks comparing the current method with the patch that=
 reduces everything to one call.  I write a number of 10k binaries to a fil=
e, then read them back in a random order from 1/5/10/20 concurrent reader p=
rocesses.  I report the median/90/95/99 percentile response times in micros=
econds.  In almost every case the patch is an improvement.
> The data was fully cached for these tests; I think that in a real-world c=
oncurrent reader scenario the performance improvement may be greater.  The =
patch ensures that the 2-3 pread calls reading sequential bits of data (ter=
m length, MD5, and term) are always submitted without interruption.  Previo=
usly, two concurrent readers could race to read different terms and cause s=
ome extra disk head movement.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.