[
https://issues.apache.org/jira/browse/COUCHDB-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052909#comment-14052909
]
Benoit Chesneau commented on COUCHDB-2097:
------------------------------------------
Reads are not going via the updater process you're right I missed that change
in bigcouch.
Though, except if I missed something, that doesn't change a lot. Now an update
update the latest db value by sending a message to the couch_server process
which update the ets (shared between all dbs). Then on read you open the db by
sending a message to the couch_server and then read the ets from it . The
couch_server is now the new bottleneck. It could be improved there by using a
protected ets and accessing directly to it on open, but some tests recently on
similar design showed that relying on ets for that is slowing things compared
to access to one process.
I understand why you did that change. But serialising read and writes is not a
good idea imo. Where we really only want serialibility. And we should fix the
regression which is not only about performance.
I don't think we should simply closing the ticket and forget it. Maybe you're
right we should to supercede it by a new new ticket linking to this one. All
these changes could happen in master anyway, I don't think it is blocking the
merge.
> Avoid performance regression with a single fd
> ---------------------------------------------
>
> Key: COUCHDB-2097
> URL: https://issues.apache.org/jira/browse/COUCHDB-2097
> 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
(v6.2#6252)
