[
https://issues.apache.org/jira/browse/CASSANDRA-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14745669#comment-14745669
]
Benedict commented on CASSANDRA-10326:
--------------------------------------
bq. Basically, the more complete picture we have, the more likely we are to
know where we should start looking for inefficiencies.
Agreed. I picked reverse queries quite arbitrarily, since we haven't (to my
knowledge) tested this previously, and this is the complete picture we have
currently, and we should certainly consider kicking off a batch of similar
tests exploring the option space (I had a lengthier blurb explaining this, but
I clearly trimmed it when I got too long).
It's also worth noting I just ran a comparison for more efficient {{skipBytes}}
[here|http://cstar.datastax.com/graph?stats=e31e6c18-5baf-11e5-b176-42010af0688f&metric=op_rate&operation=1_user&smoothing=1&show_aggregates=true&xmin=0&xmax=3423.09&ymin=0&ymax=143052.8]
and the results were significantly worse, which makes no sense at all (at
best, I'd expect no difference). So there may also be issues with consistency
of results at play. However the results I filed against this ticket were
remarkably consistent across runs.
> Performance is worse in 3.0
> ---------------------------
>
> Key: CASSANDRA-10326
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10326
> Project: Cassandra
> Issue Type: Bug
> Reporter: Benedict
> Priority: Critical
> Fix For: 3.0.x
>
>
> Performance is generally turning out to be worse after 8099, despite a number
> of unrelated performance enhancements being delivered. This isn't entirely
> unexpected, given a great deal of time was spent optimising the old code,
> however things appear worse than we had hoped.
> My expectation was that workloads making extensive use of CQL constructs
> would be faster post-8099, however the latest tests performed with very large
> CQL rows, including use of collections, still exhibit performance below that
> of 2.1 and 2.2.
> Eventually, as the dataset size grows large enough and the locality of access
> is just right, the reduction in size of our dataset will yield a window
> during which some users will perform better due simply to improved page cache
> hit rates. We seem to see this in some of the tests. However we should be at
> least as fast (and really faster) off the bat.
> The following are some large partition benchmark results, with as many as 40K
> rows per partition, running LCS. There are a number of parameters we can
> modify to see how behaviour changes and under what scenarios we might still
> be faster, but the picture painted isn't brilliant, and is consistent, so we
> should really try and figure out what's up before GA.
> [trades-with-flags (collections),
> blade11b|http://cstar.datastax.com/graph?stats=f0a17292-5a13-11e5-847a-42010af0688f&metric=op_rate&operation=1_user&smoothing=1&show_aggregates=true&xmin=0&xmax=4387.02&ymin=0&ymax=122951.4]
> [trades-with-flags (collections),
> blade11|http://cstar.datastax.com/graph?stats=e25aaaa0-5a13-11e5-ae0d-42010af0688f&metric=op_rate&operation=1_user&smoothing=1&show_aggregates=true&xmin=0&xmax=4424.75&ymin=0&ymax=130158.6]
> [trades (no collections),
> blade11|http://cstar.datastax.com/graph?stats=9b7da48e-570c-11e5-90fe-42010af0688f&metric=op_rate&operation=1_user&smoothing=1&show_aggregates=true&xmin=0&xmax=2682.46&ymin=0&ymax=142547.9]
> [~slebresne]: will you have time to look into this before GA?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
