[
https://issues.apache.org/jira/browse/CASSANDRA-6976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14228737#comment-14228737
]
Benedict commented on CASSANDRA-6976:
-------------------------------------
[~jbellis] [~aweisberg] I have a few remaining concerns, although I agree this
isn't _super_ pressing:
* the benchmark as tested will have perfect L1 cache occupancy, which in a real
scenario is unlikely
* the benchmarks did not account for: (all of which should have a negative
impact on the runtime on getRangeSlice itself)
** running with dynamic snitch (that is being updated simultaneously)
** running with network topology snitch underneath the dynamic snitch, and/or
by itself
** running with, say, 3+ DCs, RF>=3
the benchmark looks like it ran with simplesnitch, RF=1, 1 DC - i.e., ideal
conditions.
This won't likely make an order of magnitude difference, but I guess the
question is if we care about being tremendously slow for full table scans for
_small_ tables. Programmatically fetching the entire contents of a lookup
table, for instance, would be badly affected by this behaviour even without the
changes I propose to the methodology.
> Determining replicas to query is very slow with large numbers of nodes or
> vnodes
> --------------------------------------------------------------------------------
>
> Key: CASSANDRA-6976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6976
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Benedict
> Assignee: Ariel Weisberg
> Labels: performance
> Attachments: GetRestrictedRanges.java, jmh_output.txt,
> jmh_output_murmur3.txt, make_jmh_work.patch
>
>
> As described in CASSANDRA-6906, this can be ~100ms for a relatively small
> cluster with vnodes, which is longer than it will spend in transit on the
> network. This should be much faster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
