Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Message-ID: <7811086.46791273859202719.JavaMail.jira@thor>
Date: Fri, 14 May 2010 13:46:42 -0400 (EDT)
From: "Adam Kocoloski (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Subject: [jira] Closed: (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: 7bit


     [ https://issues.apache.org/jira/browse/COUCHDB-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adam Kocoloski closed COUCHDB-762.
----------------------------------

    Resolution: Fixed

applied v2 of the patch

> 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, patch-to-reproduce-benchmarks.txt, pread_iolist_bench.erl, pread_iolist_results.txt
>
>
> couch_file's pread_iolist function is used every time we read anything from 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 gen_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 file, then read them back in a random order from 1/5/10/20 concurrent reader processes.  I report the median/90/95/99 percentile response times in microseconds.  In almost every case the patch is an improvement.
> The data was fully cached for these tests; I think that in a real-world concurrent reader scenario the performance improvement may be greater.  The patch ensures that the 2-3 pread calls reading sequential bits of data (term length, MD5, and term) are always submitted without interruption.  Previously, two concurrent readers could race to read different terms and cause some extra disk head movement.

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