cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Tolbert (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-9558) Cassandra-stress regression in 2.2
Date Sat, 06 Jun 2015 06:43:00 GMT

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

Andy Tolbert edited comment on CASSANDRA-9558 at 6/6/15 6:42 AM:
-----------------------------------------------------------------

Think I've gotten to the bottom of this.  Attached is [^CASSANDRA-9558-2.patch] (should apply
cleanly on both cassandra-2.2 and trunk) which does the following:

* Forces Protocol Version to V2 in driver client used by cassandra-stress.  This is necessary
to enable the driver to use more 1 connection per host (explanation above).
* Explicitly set core connections to 8 from 2.   The previous java-driver used for cassandra-stress,
2.0.9.2, was set up to use 8 core connections to get around a pool growth/shrinking issue
introduced in an earlier version which has since been fixed.  It turns out more connections
= better performance in a high stress scenario.  When using default settings, the size of
the pool grows to about 3-4 to meet the number of simultaneous requests I'd expect to see
in this configuration w/ 300 threads.
* Remove netty-3.9.0.Final.jar from tools/lib as both C* and stress tool are using a shaded
version of the driver which provides netty itself, so this is no longer needed.   Also removed
references to tools/lib from build.xml as this directory is now empty.

With these changes I am now seeing comparable if not slightly better performance than the
stress tool on cassandra-2.1 using driver 2.0.9.2.  Here's a sampling of the results I've
captures (attached as [^atolber-CASSANDRA-9558-stress.tgz]).

I also ran with 4, 16 and 32 core connections.    There was a slight improvement at 16, but
a degradation at 32.   It might interesting to make this option configurable in the future,
but I think 8 is a happy medium for now and decided to stick to it to operate similarly to
stress on the 2.1 branch.

||Description||branch||write ops rate||
|2.0.9.2 driver|cassandra-2.1|136579|
|2.0.9.2 driver|trunk|138659|
|2.2.0-rc1|trunk|74100|
|2.2.0-rc1 proto v2, 4 core connections|trunk|127211|
|2.2.0-rc1 proto v2, 8 core connections|trunk|142450|
|2.2.0-rc1 proto v2, 16 core connections|trunk|144077|
|2.2.0-rc1 proto v2, 32 core connections|trunk|129678|


was (Author: andrew.tolbert):
Think I've gotten to the bottom of this.  Attached is [^CASSANDRA-9558-2.patch] which does
the following:

* Forces Protocol Version to V2 in driver client used by cassandra-stress.  This is necessary
to enable the driver to use more 1 connection per host (explanation above).
* Explicitly set core connections to 8 from 2.   The previous java-driver used for cassandra-stress,
2.0.9.2, was set up to use 8 core connections to get around a pool growth/shrinking issue
introduced in an earlier version which has since been fixed.  It turns out more connections
= better performance in a high stress scenario.  When using default settings, the size of
the pool grows to about 3-4 to meet the number of simultaneous requests I'd expect to see
in this configuration w/ 300 threads.
* Remove netty-3.9.0.Final.jar from tools/lib as both C* and stress tool are using a shaded
version of the driver which provides netty itself, so this is no longer needed.   Also removed
references to tools/lib from build.xml as this directory is now empty.

With these changes I am now seeing comparable if not slightly better performance than the
stress tool on cassandra-2.1 using driver 2.0.9.2.  Here's a sampling of the results I've
captures (attached as [^atolber-CASSANDRA-9558-stress.tgz]).

I also ran with 4, 16 and 32 core connections.    There was a slight improvement at 16, but
a degradation at 32.   It might interesting to make this option configurable in the future,
but I think 8 is a happy medium for now and decided to stick to it to operate similarly to
stress on the 2.1 branch.

||Description||branch||write ops rate||
|2.0.9.2 driver|cassandra-2.1|136579|
|2.0.9.2 driver|trunk|138659|
|2.2.0-rc1|trunk|74100|
|2.2.0-rc1 proto v2, 4 core connections|trunk|127211|
|2.2.0-rc1 proto v2, 8 core connections|trunk|142450|
|2.2.0-rc1 proto v2, 16 core connections|trunk|144077|
|2.2.0-rc1 proto v2, 32 core connections|trunk|129678|

> Cassandra-stress regression in 2.2
> ----------------------------------
>
>                 Key: CASSANDRA-9558
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9558
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Alan Boudreault
>            Priority: Blocker
>         Attachments: 2.1.log, 2.2.log, CASSANDRA-9558-2.patch, CASSANDRA-9558-ProtocolV2.patch,
atolber-CASSANDRA-9558-stress.tgz, stress-2.1-java-driver-2.0.9.2.log, stress-2.1-java-driver-2.2+PATCH.log,
stress-2.1-java-driver-2.2.log, stress-2.2-java-driver-2.2+PATCH.log, stress-2.2-java-driver-2.2.log
>
>
> We are seeing some regression in performance when using cassandra-stress 2.2. You can
see the difference at this url:
> http://riptano.github.io/cassandra_performance/graph_v5/graph.html?stats=stress_regression.json&metric=op_rate&operation=1_write&smoothing=1&show_aggregates=true&xmin=0&xmax=108.57&ymin=0&ymax=168147.1
> The cassandra version of the cluster doesn't seem to have any impact. 
> //cc [~tjake] [~benedict]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message