[ https://issues.apache.org/jira/browse/COUCHDB-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13152022#comment-13152022
]
Robert Newson commented on COUCHDB-1342:
----------------------------------------
@Damien, thanks for the clarification. It's possible to read what you originally wrote as
an intention to dismiss concerns over introducing further complexity as long as it improved
performance. Since Paul has now explicitly described several technical problems with the patch
I'm sure we can all move on to addressing them. I'll only add that I had read the entire page
on voting and didn't feel that the section you highlighted applied in this case, which is
why I didn't mention it myself.
I would like to know why couch_file now needs two file descriptors to provide asynchronous
writes, though. If it's integral, I'd appreciate knowing why, and whether there are alternatives.
If not, a separate ticket seems appropriate. The only thing I can think of is the inability
to usefully pass a handle to a file opened with [raw] between processes. In any case, doubling
the consumption of precious server resources should be called out explicitly, rather than
incidentally, in my opinion.
Am I also right in thinking that the improved write performance entails increased memory usage
(and therefore increased GC too)? What's the impact of that on very busy servers?
> Asynchronous file writes
> ------------------------
>
> Key: COUCHDB-1342
> URL: https://issues.apache.org/jira/browse/COUCHDB-1342
> Project: CouchDB
> Issue Type: Improvement
> Components: Database Core
> Reporter: Jan Lehnardt
> Fix For: 1.3
>
> Attachments: COUCHDB-1342.patch
>
>
> This change updates the file module so that it can do
> asynchronous writes. Basically it replies immediately
> to process asking to write something to the file, with
> the position where the chunks will be written to the
> file, while a dedicated child process keeps collecting
> chunks and write them to the file (and batching them
> when possible). After issuing a series of write request
> to the file module, the caller can call its 'flush'
> function which will block the caller until all the
> chunks it requested to write are effectively written
> to the file.
> This maximizes the IO subsystem, as for example, while
> the updater is traversing and modifying the btrees and
> doing CPU bound tasks, the writes are happening in
> parallel.
> Originally described at http://s.apache.org/TVu
> Github Commit: https://github.com/fdmanana/couchdb/commit/e82a673f119b82dddf674ac2e6233cd78c123554
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira