[
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-v2.patch
An even better patch which does exactly 2 pread() calls in all cases, even for
MD5-prefixed terms. Here are updated timings, with this approach termed
'pread_iolist_3':
4> pread_iolist_bench:go(5000, 10000, 1, pread_iolist).
Median 96
90% 103
95% 109
99% 153
ok
5> pread_iolist_bench:go(5000, 10000, 1, pread_iolist2).
Median 82
90% 90
95% 94
99% 107
ok
6> pread_iolist_bench:go(5000, 10000, 1, pread_iolist3).
Median 71
90% 78
95% 81
99% 93
ok
> 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.
