[
https://issues.apache.org/jira/browse/CASSANDRA-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13998622#comment-13998622
]
Benedict edited comment on CASSANDRA-4718 at 5/15/14 9:30 AM:
--------------------------------------------------------------
bq. (latest bdplab tests)
Which latest bdplab tests? The longer bdplab test from before (not the latest
tests) had some issues (unrelated to this ticket) so we didn't get any read
results, but showed increased write throughput.
The latest tests have all been short runs. I am actually very pleased we are
_at all_ faster on bdplab for any workload, as the first versions of these
patches did not seem to benefit older hardware/kernels (we don't have enough
hardware configurations to say which was the deciding factor), and actually
incurred a slight penalty. The fact that the gap is very narrow for bdplab is
not really important, nor are the thrift numbers. In both of those instances
the interesting thing is only that we _do not perform any worse_; performing
slightly better even here is just a bonus.
was (Author: benedict):
bq. (latest bdplab tests)
Which latest bdplab tests? The longer bdplab test from before (not the latest
tests) had some issues (unrelated to this ticket) so we didn't get any read
results, but showed increased write throughput.
The latest tests have all been short runs. I am actually very pleased we are
_at all_ faster for bdplab on any workload, as the first versions of these
patches did not seem to benefit older hardware/kernels (we don't have enough
hardware configurations to say which was the deciding factor), and actually
incurred a slight penalty. The fact that the gap is very narrow for bdplab is
not really important, nor are the thrift numbers. In both of those instances I
am interested only in that we _do not perform any worse_; performing slightly
better even here is just a bonus.
> 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, 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, 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)
