[
https://issues.apache.org/jira/browse/CASSANDRA-975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878708#action_12878708
]
Jonathan Ellis commented on CASSANDRA-975:
------------------------------------------
how important is the new "concurrency" parameter? could setting that
relatively high compared to the number of cores (64 in this patch) cause part
of the performance regression?
we could set it to the number of reader threads, but that would require making
the map volatile (so we can recreate it if reader thread count changes), which
is another (minor) performance hit. so if this is just being used as a lock
shard count for instance then setting it to something safely high would be my
preferred way to go.
> explore upgrading CLHM
> ----------------------
>
> Key: CASSANDRA-975
> URL: https://issues.apache.org/jira/browse/CASSANDRA-975
> Project: Cassandra
> Issue Type: Task
> Reporter: Jonathan Ellis
> Assignee: Matthew F. Dennis
> Priority: Minor
> Fix For: 0.8
>
> Attachments: 0001-trunk-975.patch, clhm_test_results.txt,
> insertarator.py, readarator.py
>
>
> The new version should be substantially better "on large caches where many
> entries were readon large caches where many entries were read," which is
> exactly what you see in our row and key caches.
> http://code.google.com/p/concurrentlinkedhashmap/issues/detail?id=9
> Hopefully we can get Digg to help test, since they could reliably break CLHM
> when it was buggy.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
