[jira] [Updated] (CASSANDRA-8449) Allow zero-copy reads again

2018-11-18 Thread C. Scott Andreas (JIRA)


 [ 
https://issues.apache.org/jira/browse/CASSANDRA-8449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

C. Scott Andreas updated CASSANDRA-8449:

Component/s: Local Write-Read Paths

> Allow zero-copy reads again
> ---
>
> Key: CASSANDRA-8449
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8449
> Project: Cassandra
>  Issue Type: Improvement
>  Components: Local Write-Read Paths
>Reporter: T Jake Luciani
>Priority: Minor
>  Labels: performance
> Fix For: 4.x
>
>
> We disabled zero-copy reads in CASSANDRA-3179 due to in flight reads 
> accessing a ByteBuffer when the data was unmapped by compaction.  Currently 
> this code path is only used for uncompressed reads.
> The actual bytes are in fact copied to the client output buffers for both 
> netty and thrift before being sent over the wire, so the only issue really is 
> the time it takes to process the read internally.  
> This patch adds a slow network read test and changes the tidy() method to 
> actually delete a sstable once the readTimeout has elapsed giving plenty of 
> time to serialize the read.
> Removing this copy causes significantly less GC on the read path and improves 
> the tail latencies:
> http://cstar.datastax.com/graph?stats=c0c8ce16-7fea-11e4-959d-42010af0688f=gc_count=2_read=1_aggregates=true=0=109.34=0=5.5



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org



[jira] [Updated] (CASSANDRA-8449) Allow zero-copy reads again

2015-10-26 Thread T Jake Luciani (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-8449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

T Jake Luciani updated CASSANDRA-8449:
--
Assignee: (was: T Jake Luciani)

> Allow zero-copy reads again
> ---
>
> Key: CASSANDRA-8449
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8449
> Project: Cassandra
>  Issue Type: Improvement
>Reporter: T Jake Luciani
>Priority: Minor
>  Labels: performance
> Fix For: 3.x
>
>
> We disabled zero-copy reads in CASSANDRA-3179 due to in flight reads 
> accessing a ByteBuffer when the data was unmapped by compaction.  Currently 
> this code path is only used for uncompressed reads.
> The actual bytes are in fact copied to the client output buffers for both 
> netty and thrift before being sent over the wire, so the only issue really is 
> the time it takes to process the read internally.  
> This patch adds a slow network read test and changes the tidy() method to 
> actually delete a sstable once the readTimeout has elapsed giving plenty of 
> time to serialize the read.
> Removing this copy causes significantly less GC on the read path and improves 
> the tail latencies:
> http://cstar.datastax.com/graph?stats=c0c8ce16-7fea-11e4-959d-42010af0688f=gc_count=2_read=1_aggregates=true=0=109.34=0=5.5



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (CASSANDRA-8449) Allow zero-copy reads again

2014-12-09 Thread T Jake Luciani (JIRA)

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-8449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

T Jake Luciani updated CASSANDRA-8449:
--
Labels: performance  (was: )

 Allow zero-copy reads again
 ---

 Key: CASSANDRA-8449
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8449
 Project: Cassandra
  Issue Type: Improvement
Reporter: T Jake Luciani
Priority: Minor
  Labels: performance
 Fix For: 3.0


 We disabled zero-copy reads in CASSANDRA-3179 due to in flight reads 
 accessing a ByteBuffer when the data was unmapped by compaction.  Currently 
 this code path is only used for uncompressed reads.
 The actual bytes are in fact copied to the client output buffers for both 
 netty and thrift before being sent over the wire, so the only issue really is 
 the time it takes to process the read internally.  
 This patch adds a slow network read test and changes the tidy() method to 
 actually delete a sstable once the readTimeout has elapsed giving plenty of 
 time to serialize the read.
 Removing this copy causes significantly less GC on the read path and improves 
 the tail latencies:
 http://cstar.datastax.com/graph?stats=c0c8ce16-7fea-11e4-959d-42010af0688fmetric=gc_countoperation=2_readsmoothing=1show_aggregates=truexmin=0xmax=109.34ymin=0ymax=5.5



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)