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

Benedict commented on CASSANDRA-6553:
-------------------------------------

bq.  ./bin/cassandra-stress counterwrite n=1000000 -key populate=1..3 -col 
n=FIXED\(1\) -col n=FIXED\(2\) -col n=FIXED\(3\)

This should throw an error. If it doesn't, it's a bug. Defining col three times 
doesn't mean you get three different col definitions. Unless this is a typo, 
you'd want something like:

bq. -col n=uniform(1..3)

Although perhaps we should introduce a new distribution that walks through all 
values, as populate does for -key.

Also, your first two tests look particularly similar; it's unlikely one will 
yield any more useful information than another (N threads to two partitions is 
probably roughly the same as N/2 threads to one, unless we saturate the network)

It might be worth throwing a mixed workload in there, to shake things up a 
little, e.g. (50/50 split):

cassandra-stress mixed clustering=exp\(1..10\) 
ratio\(counterread=1,counterwrite=1\)

Looking at this, I realise the "clustering" option is poorly documented, in 
fact it doesn't say anything about what it does. I'll fix that. It "clusters" 
commands; i.e. when selecting a new command, defines how many of that command 
type will be executed before a different command type is selected.

> Benchmark counter improvements (counters++)
> -------------------------------------------
>
>                 Key: CASSANDRA-6553
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6553
>             Project: Cassandra
>          Issue Type: Test
>            Reporter: Ryan McGuire
>            Assignee: Russ Hatch
>             Fix For: 2.1 beta2
>
>
> Benchmark the difference in performance between CASSANDRA-6504 and trunk.
> * Updating totally unrelated counters (different partitions)
> * Updating the same counters a lot (same cells in the same partition)
> * Different cells in the same few partitions (hot counter partition)
> benchmark: 
> https://github.com/apache/cassandra/tree/1218bcacba7edefaf56cf8440d0aea5794c89a1e
>  (old counters)
> compared to: 
> https://github.com/apache/cassandra/tree/714c423360c36da2a2b365efaf9c5c4f623ed133
>  (new counters)
> So far, the above changes should only affect the write path.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to