cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ariel Weisberg (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10326) Performance is worse in 3.0
Date Mon, 16 Nov 2015 22:10:11 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-10326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15007450#comment-15007450
] 

Ariel Weisberg commented on CASSANDRA-10326:
--------------------------------------------

I am trying to run [this client workload|http://cstar.datastax.com/graph?stats=518e5484-5ee3-11e5-b421-42010af0688f&metric=99.9th_latency&operation=1_user&smoothing=1&show_aggregates=true&xmin=0&xmax=865.37&ymin=0&ymax=158.51]
on my laptop (server is on another box) and it is burning through the entire CPU. I profiled
with flight recorder and it looks like it spends a lot of time o.a.c.stress.generate.PartitionIterator$MultiRowIterator.

It's not light on GC load either with frequent several hundred millisecond pauses.

I guess I will have to track down some beefier hardware, but it does make me wonder what is
going on when we take measurements.

> 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
>            Assignee: Ariel Weisberg
>             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)

Mime
View raw message