cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (CASSANDRA-1651) Improve read performance by using byte array slabs
Date Fri, 29 Oct 2010 19:22:24 GMT

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

Jonathan Ellis edited comment on CASSANDRA-1651 at 10/29/10 3:21 PM:
---------------------------------------------------------------------

bq. if a key/name was going to live in memory for a while, we would intern it

Is there a hole in this reasoning?

 1. the only place we have these live in memory for a while is the key and row caches; everything
else only lasts for the duration of a read which is small numbers of ms at most (i.e. less
than the time between new or old gen GC runs)
 2. if you are reading the same sequence multiple times without using key/row cache then you
are not configuring optimally so we can dismiss this scenario as uninteresting
 3. we have to read it (or wrap it) the sequence into a new buffer to do the cache lookup;
at this point the allocation has been done and replacing it with an interned version doesn't
matter since GCing now vs GCing when the read finishes in a ms is going to be part of the
same GC generation

      was (Author: jbellis):
    bq. if a key/name was going to live in memory for a while, we would intern it

Is there a hole in this reasoning?

 1. the only place we have these live in memory for a while is the key and row caches; everything
else only lasts for the duration of a read which is small numbers of ms at most (i.e. less
than the time between new or old gen GC runs)
 2. if you are reading the same sequence multiple times then you should be using a key/row
cache; it is silly to discuss interning w/o this
 3. we have to read it (or wrap it) the sequence into a new buffer to do the cache lookup;
at this point the allocation has been done and replacing it with an interned version doesn't
matter since GCing now vs GCing when the read finishes in a ms is going to be part of the
same GC generation
  
> Improve read performance by using byte array slabs
> --------------------------------------------------
>
>                 Key: CASSANDRA-1651
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1651
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: T Jake Luciani
>            Assignee: T Jake Luciani
>            Priority: Minor
>             Fix For: 0.7.0
>
>         Attachments: 1651_v1.txt
>
>
> Now that the code has switched to byte buffers internally,  it should be possible to
improve read performance by reducing the number of byte array allocations.
> This patch accomplishes this by and re-using sections of a larger byte array slab.
> I've benchmarked it locally and seen a slight improvement on reads, a larger scale benchmark
should be performed.
> Also the size of a slab can be configured in cassandra.yaml

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message