[
https://issues.apache.org/jira/browse/COUCHDB-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14631572#comment-14631572
]
ASF subversion and git services commented on COUCHDB-2732:
----------------------------------------------------------
Commit 6b38dfacbb97c5cb7c89a27115d1227c7c52dbba in couchdb-couch's branch
refs/heads/master from [~paul.joseph.davis]
[ https://git-wip-us.apache.org/repos/asf?p=couchdb-couch.git;h=6b38dfa ]
Optimize couch_ejson_compare NIF
The old nif was allocating a set of collators that were reserved and
released by each scheduler thread. This coordination and the
accompanying mutex turned into a global point of contention when many
schedulers were using couch_ejson_compare.
This change removes the stack based concurrency control in favor of a
`__thread variable`. We end up with the same number of collators but
without any overhead around locking a central mutex.
This increases performance by roughly a factor of five.
COUCHDB-2732
> Use thread local storage for couch_ejson_compare NIF
> ----------------------------------------------------
>
> Key: COUCHDB-2732
> URL: https://issues.apache.org/jira/browse/COUCHDB-2732
> Project: CouchDB
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Reporter: Adam Kocoloski
>
> Some folks inside IBM have demonstrated conclusively that the NIF we use for
> JSON sorting is a significant bottleneck with more than a few concurrent
> users hitting us. The VM ends up spending all of its time dealing with lock
> contention. We'd be better off sticking with the pure Erlang code, but we
> have an even better alternative, which is to use thread local storage to pin
> an allocator to each OS thread and eliminate the locks.
> Patch forthcoming, but I wanted to make sure this got in the tracker. The
> improvement looks really signficant. Interestingly, there was some discussion
> about a performance regression after this was introduced back in COUCHDB-1186
> ... maybe the missing element in that discussion was the client concurrency?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
