cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6976) Determining replicas to query is very slow with large numbers of nodes or vnodes
Date Sun, 30 Nov 2014 23:18:13 GMT


Benedict commented on CASSANDRA-6976:

On second thoughts, ignore that sentiment entirely. We don't really have any concept of a
"lookup table", and we'll have to address that directly when we introduce enum types which
is a better place. 

I guess what really bugs me about this, and what I assumed would be related to the problem
(but patently can't given the default behaviour) is that after calculating natural endpoints,
we then sort them (based on a couple of hashmap lookups for each end point) for every token
range, and also for every single normal query. This sort is performed over RF*DC items in
either case, even for queries routed directly to the owning node with CL ONE. I was hoping
we'd fix that as a result of this work, since that's a lot of duplicated effort, but that
hardly seems sensible now. What we definitely _should_ do, though, is make sure we're (in
general) benchmarking behaviour over common config, as our default test configuration is not
at all representative.

> Determining replicas to query is very slow with large numbers of nodes or vnodes
> --------------------------------------------------------------------------------
>                 Key: CASSANDRA-6976
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Benedict
>            Assignee: Ariel Weisberg
>              Labels: performance
>         Attachments:, jmh_output.txt, jmh_output_murmur3.txt,
> 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

This message was sent by Atlassian JIRA

View raw message