[
https://issues.apache.org/jira/browse/CASSANDRA-7519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14100233#comment-14100233
]
T Jake Luciani commented on CASSANDRA-7519:
-------------------------------------------
I'm not very keen on the new labels you've chosen for the insert section of the
yaml file, They should be more verbose.
Batch size - "number of unique partitions to update in a single operation"
This should mention partitions in it no? partitions_per_batch maybe?
Batch count - "number of batches we aim to split the update up into"
Does this mean the number of batches to split a operation of N partitions
into? If so, then perhaps batch_split_count?
I plan to run some test workloads to double check the logic, but first cut of
the code looked good. I left a couple comments on the github branch
> Further stress improvements to generate more realistic workloads
> ----------------------------------------------------------------
>
> Key: CASSANDRA-7519
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7519
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Benedict
> Assignee: Benedict
> Priority: Minor
> Labels: tools
> Fix For: 2.1.1
>
>
> We generally believe that the most common workload is for reads to
> exponentially prefer most recently written data. However as stress currently
> behaves we have two id generation modes: sequential and random (although
> random can be distributed). I propose introducing a new mode which is
> somewhat like sequential, except we essentially 'look back' from the current
> id by some amount defined by a distribution. I may possibly make the position
> only increment as it's first written to also, so that this mode can be run
> from a clean slate with a mixed workload. This should allow is to generate
> workloads that are more representative.
> At the same time, I will introduce a timestamp value generator for primary
> key columns that is strictly ascending, i.e. has some random component but is
> based off of the actual system time (or some shared monotonically increasing
> state) so that we can again generate a more realistic workload. This may be
> challenging to tie in with the new procedurally generated partitions, but I'm
> sure it can be done without too much difficulty.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
