[ 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)