[
https://issues.apache.org/jira/browse/CASSANDRA-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14000727#comment-14000727
]
Benedict commented on CASSANDRA-4718:
-------------------------------------
Whilst on this topic, I've been thinking about disk/memory testing protocols in
general, and it seems we really need to think through a good strategy for
creating a consistent test bed that is representative. The test I have asked
[~enigmacurry] to run is not going to be fair, as major compaction will cause
all of the data points to be randomly distributed (by hash) across a single
sstable, and given the records are small, selecting from a smallish random
subset of this data will pretty much necessarily involve touching every page on
disk with equal probability. However disabling compaction entirely is equally
unfair, as we leave many sstables to check from bloom filter false positives
(there are around 800+ sstables in Jason's test, for 300Gb of data, at a finger
in air estimate), so most of the cache will be going to index files, with
almost every data item lookup probably going to disk due to the reduced memory
causing the same effect as the major compaction to kick in.
It seems to me we need to 1) get the exponential distribution to select from
last keys in preference to first keys (i.e. most recently written most commonly
accessed); and 2) create a compaction strategy for testing purposes, that is
designed to create a sort-of "in flight snapshot" of a real STCS workload, by
compacting older data into exponentially larger files. These two together
should give us much closer to a real live system that is using STCS, and with a
consistent reproducible baseline behaviour.
> More-efficient ExecutorService for improved throughput
> ------------------------------------------------------
>
> Key: CASSANDRA-4718
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4718
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Assignee: Benedict
> Priority: Minor
> Labels: performance
> Fix For: 2.1.0
>
> Attachments: 4718-v1.patch, PerThreadQueue.java,
> austin_diskbound_read.svg, aws.svg, aws_read.svg,
> backpressure-stress.out.txt, baq vs trunk.png,
> belliotsmith_branches-stress.out.txt, jason_read.svg, jason_read_latency.svg,
> jason_write.svg, op costs of various queues.ods, stress op rate with various
> queues.ods, stress_2014May15.txt, stress_2014May16.txt, v1-stress.out
>
>
> Currently all our execution stages dequeue tasks one at a time. This can
> result in contention between producers and consumers (although we do our best
> to minimize this by using LinkedBlockingQueue).
> One approach to mitigating this would be to make consumer threads do more
> work in "bulk" instead of just one task per dequeue. (Producer threads tend
> to be single-task oriented by nature, so I don't see an equivalent
> opportunity there.)
> BlockingQueue has a drainTo(collection, int) method that would be perfect for
> this. However, no ExecutorService in the jdk supports using drainTo, nor
> could I google one.
> What I would like to do here is create just such a beast and wire it into (at
> least) the write and read stages. (Other possible candidates for such an
> optimization, such as the CommitLog and OutboundTCPConnection, are not
> ExecutorService-based and will need to be one-offs.)
> AbstractExecutorService may be useful. The implementations of
> ICommitLogExecutorService may also be useful. (Despite the name these are not
> actual ExecutorServices, although they share the most important properties of
> one.)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
