incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Kocoloski (JIRA)" <j...@apache.org>
Subject [jira] Updated: (COUCHDB-762) Faster implementation of couch_file:pread_iolist
Date Fri, 14 May 2010 15:37:43 GMT

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

Adam Kocoloski updated COUCHDB-762:
-----------------------------------

    Attachment: 762-pread_iolist.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.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.


Mime
View raw message