[
https://issues.apache.org/jira/browse/CASSANDRA-6995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962624#comment-13962624
]
Pavel Yaskevich commented on CASSANDRA-6995:
--------------------------------------------
bq. "can we detect, further upstream (before SP), which stage we'll eventually
use, and use it locally on the coordinator"
Exactly, we should be able to separate the detection logic and use it in
thrift/cql instead of SP, so we can schedule directly to appropriate stage,
even thought you would context switch for non-local reads that's what we do
anyway with I/O worker pool (to the different COORDINATOR stage or similar).
bq. A given node's stages will be contended for by both coordinator use and
data node uses. This perhaps would suggest a model similar to what Benedict
mentioned earlier, a semaphore to limit the uses of an individual stage.
I think we can schedule pure coordinator requests to the separate stage (when
it doesn't do any operations except forwarding requests) that doesn't break
SEDA and it's mostly network I/O so why to bother actual data stages. In terms
of remote read/write requests I think they should be treated in the same
concurrency quota as thrift/cql requests and they take as such system resource
so scheduling them to the same stages would provide appropriate back-pressure
the client instead of internally overloading the system (e.g. previous counter
implementation did just take with separate replication stage).
> Execute local ONE/LOCAL_ONE reads on request thread instead of dispatching to
> read stage
> ----------------------------------------------------------------------------------------
>
> Key: CASSANDRA-6995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6995
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Jason Brown
> Assignee: Jason Brown
> Priority: Minor
> Labels: performance
> Fix For: 2.0.7
>
> Attachments: 6995-v1.diff, syncread-stress.txt
>
>
> When performing a read local to a coordinator node, AbstractReadExecutor will
> create a new SP.LocalReadRunnable and drop it into the read stage for
> asynchronous execution. If you are using a client that intelligently routes
> read requests to a node holding the data for a given request, and are using
> CL.ONE/LOCAL_ONE, the enqueuing SP.LocalReadRunnable and waiting for the
> context switches (and possible NUMA misses) adds unneccesary latency. We can
> reduce that latency and improve throughput by avoiding the queueing and
> thread context switching by simply executing the SP.LocalReadRunnable
> synchronously in the request thread. Testing on a three node cluster (each
> with 32 cpus, 132 GB ram) yields ~10% improvement in throughput and ~20%
> speedup on avg/95/99 percentiles (99.9% was about 5-10% improvement).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
