[
https://issues.apache.org/jira/browse/COUCHDB-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15277083#comment-15277083
]
ASF subversion and git services commented on COUCHDB-2984:
----------------------------------------------------------
Commit 130efcd6b0b6f9fa6403e131586dfbf003643074 in couchdb-mem3's branch
refs/heads/master from [~banjiewen]
[ https://git-wip-us.apache.org/repos/asf?p=couchdb-mem3.git;h=130efcd ]
Use ets:select/2 to retrieve shards by name
The result of mem3_shards:for_db/1 on databases with high q values can
be very large, resulting in suboptimal performance for high-volume
callers.
mem3_sync_event_listener is only interested in a small subset of the
result of mem3_shards:for_db/1; moving this filter in to an ets:select/2
call improves performance significantly.
COUCHDB-2984
> mem3_sync event listener performance degrades with high q values
> ----------------------------------------------------------------
>
> Key: COUCHDB-2984
> URL: https://issues.apache.org/jira/browse/COUCHDB-2984
> Project: CouchDB
> Issue Type: Improvement
> Reporter: Benjamin Anderson
>
> High throughput applications on databases with high (300+) q values have a
> tendency to cause very poor performance. While I don't fully understand the
> issue at hand, one clear manifestation is in mem3_sync's event listener. With
> high q values, the shard "selection" routine (the <<"shards/",ยท_/binary>>
> head of handle_event/3) will bottleneck on calls to mem3_shards:for_db/1 due
> to the large (tens of KB) shard maps in ETS.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
