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 <bur...@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
