cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vijay (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-6995) Execute local ONE/LOCAL_ONE reads on request thread instead of dispatching to read stage
Date Tue, 08 Apr 2014 17:07:16 GMT

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

Vijay edited comment on CASSANDRA-6995 at 4/8/14 5:05 PM:
----------------------------------------------------------

Just my 2 cents: 
I like the idea of dispatching to a separate Stages directly from thrift/native removing the
need to switch ctx, 
how about continuing the work in CASSANDRA-5239 and getting rid of io threads? (In addition
we can use the timeout thread to speculate and making storage proxy completely async post
5239?)...

In a separate note shouldn't we throttle on the number of disk read from the disk instead
of concurrent_writers and reads? its un fair on the threads when one request pulls a lot more
data than others....


was (Author: vijay2win@yahoo.com):
Just my 2 cents: 
I like the idea of dispatching to a separate TPE directly from thrift/native removing the
need to switch ctx, 
how about continuing the work in CASSANDRA-5239 and getting rid of io threads? (In addition
we can use the timeout thread to speculate and making storage proxy completely async post
5239?)...

In a separate note shouldn't we throttle on the number of disk read from the disk instead
of concurrent_writers and reads? its un fair on the threads when one request pulls a lot more
data than others....

> 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)

Mime
View raw message