cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nate McCall <n...@thelastpickle.com>
Subject Re: cassandra-stress on 3.0 with column widths benchmark.
Date Mon, 14 Sep 2015 22:27:02 GMT
By default, stress runs stop after throughput has not improved after three
runs. This functionality is a little difficult to figure out from the
documentation, so take a look at (maybe even with a debugger attached):
https://github.com/apache/cassandra/blob/cassandra-2.1/tools/stress/src/org/apache/cassandra/stress/StressAction.java#L111
to see what's going on.

In both scenarios, this may have taken roughly the same time to hit
saturation, but for different reasons and with different results as you
saw.

To really find out why, it would be a good idea to enable one of the
reporters (
http://www.datastax.com/dev/blog/pluggable-metrics-reporting-in-cassandra-2-0-2)
to send cluster metrics to a monitoring system such as Graphite. At the
very least get OpsCenter running and capturing metrics from the cluster.
Either way, getting familiar with a visual picture of the runtime now is
invaluable for really understanding any future production deployment.

On Sun, Sep 13, 2015 at 9:25 PM, Kevin Burton <burton@spinn3r.com> wrote:

> I’m trying to benchmark two scenarios…
>
> 10 columns with 150 bytes each
>
> vs
>
> 150 columns with 10 bytes each.
>
> The total row “size” would be 1500 bytes (ignoring overhead).
>
> Our app uses 150 columns so I’m trying to see if packing it into a JSON
> structure using one column would improve performance.
>
> I seem to have confirmed my hypothesis.
>
> I’m running two tests:
>
> ./tools/bin/cassandra-stress write -insert -col n=FIXED\(10\)
>> size=FIXED\(150\) | tee cassandra-stress-10-150.log
>>
>
>
>> time ./tools/bin/cassandra-stress write -insert -col n=FIXED\(150\)
>> size=FIXED\(10\) | tee cassandra-stress-150-10.log
>
>
> this shows that the "op rate” is much much lower when running with 150
> columns:
>
> root@util0063 ~/apache-cassandra-3.0.0-beta2 # grep "op rate"
>> cassandra-stress-10-150.log
>> op rate                   : 7632 [WRITE:7632]
>> op rate                   : 11851 [WRITE:11851]
>> op rate                   : 31967 [WRITE:31967]
>> op rate                   : 41798 [WRITE:41798]
>> op rate                   : 51251 [WRITE:51251]
>> op rate                   : 58057 [WRITE:58057]
>> op rate                   : 62977 [WRITE:62977]
>> op rate                   : 65398 [WRITE:65398]
>> op rate                   : 67673 [WRITE:67673]
>> op rate                   : 69198 [WRITE:69198]
>> op rate                   : 70402 [WRITE:70402]
>> op rate                   : 71019 [WRITE:71019]
>> op rate                   : 71574 [WRITE:71574]
>> root@util0063 ~/apache-cassandra-3.0.0-beta2 # grep "op rate"
>> cassandra-stress-150-10.log
>> op rate                   : 2570 [WRITE:2570]
>> op rate                   : 5144 [WRITE:5144]
>> op rate                   : 10906 [WRITE:10906]
>> op rate                   : 11832 [WRITE:11832]
>> op rate                   : 12471 [WRITE:12471]
>> op rate                   : 12915 [WRITE:12915]
>> op rate                   : 13620 [WRITE:13620]
>> op rate                   : 13456 [WRITE:13456]
>> op rate                   : 13916 [WRITE:13916]
>> op rate                   : 14029 [WRITE:14029]
>> op rate                   : 13915 [WRITE:13915]
>
>
> … what’s WEIRD here is that
>
> Both tests take about 10 minutes.  Yet it’s saying that the op rate for
> the second is slower.  Why would that be? That doesn’t make much sense…
>
> --
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> <https://plus.google.com/102718274791889610666/posts>
>
>


-- 
-----------------
Nate McCall
Austin, TX
@zznate

Co-Founder & Sr. Technical Consultant
Apache Cassandra Consulting
http://www.thelastpickle.com

Mime
View raw message