You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2016/05/09 21:30:13 UTC
[jira] [Commented] (COUCHDB-2984) mem3_sync event listener
performance degrades with high q values
[ 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)