couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Joseph Davis (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-2097) Avoid performance regression with a single fd
Date Sat, 05 Jul 2014 14:56:34 GMT


Paul Joseph Davis commented on COUCHDB-2097:


In general you're correct that having the two couch_file processes would be faster than a
single couch_file. But this was concerned with the entire stack change which includes the
change to reference counting which is required for the changes to couch_server which makes
the entire system significantly faster and more stable under load.

As to figures, Mike Wallace already did an analysis of this that I linked to earlier in this
ticket. The new version is much better for reads with the two fd version slightly better for
writes. As we've discussed previously, we can look into revamping the reference counting post-merge
and then thinking about getting this two fd version back for the minor increase in write speeds.

Given that there isn't a direct regression from this work I'd consider this ticket closed.
If you like we can open a new ticket to investigate rewriting the reference counting code
so that we can get the two fd split back in eke out the extra bit of write performance. But
given that's new development work I don't see why it should block the merge.

> Avoid performance regression with a single fd
> ---------------------------------------------
>                 Key: COUCHDB-2097
>                 URL:
>             Project: CouchDB
>          Issue Type: Improvement
>      Security Level: public(Regular issues) 
>          Components: BigCouch
>            Reporter: Paul Joseph Davis
>              Labels: release
>         Attachments: mike-wallace-fd-benchmarks.txt
> Part of one of our large enhancements required that we remove a CouchDB performance optimization
on having two file handles to each .couch file. We need to make sure that this doesn't negatively
impact performance.

This message was sent by Atlassian JIRA

View raw message