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

Ariel Weisberg commented on CASSANDRA-13241:
--------------------------------------------

Performance comparison of summing vs the larger compact sequence vs just 
fetching a long from memory. These numbers are low enough that I don't think it 
matters which we pick. For every lookup we do here we are going to do several 
microseconds of decompression and that is going to get much faster by virtue of 
decompressing less data. Decompression may also get faster due to being a 
better fit for cache.
{noformat}
     [java] Benchmark                                                           
                                       Mode  Cnt    Score   Error  Units
     [java] CompactIntegerSequenceBench.benchCompactIntegerSequence             
                                     sample    2   59.500          ns/op
     [java] 
CompactIntegerSequenceBench.benchCompactIntegerSequence:benchCompactIntegerSequence·p0.00
                sample        57.000          ns/op
     [java] 
CompactIntegerSequenceBench.benchCompactIntegerSequence:benchCompactIntegerSequence·p0.50
                sample        59.500          ns/op
     [java] 
CompactIntegerSequenceBench.benchCompactIntegerSequence:benchCompactIntegerSequence·p0.90
                sample        62.000          ns/op
     [java] 
CompactIntegerSequenceBench.benchCompactIntegerSequence:benchCompactIntegerSequence·p0.95
                sample        62.000          ns/op
     [java] 
CompactIntegerSequenceBench.benchCompactIntegerSequence:benchCompactIntegerSequence·p0.99
                sample        62.000          ns/op
     [java] 
CompactIntegerSequenceBench.benchCompactIntegerSequence:benchCompactIntegerSequence·p0.999
               sample        62.000          ns/op
     [java] 
CompactIntegerSequenceBench.benchCompactIntegerSequence:benchCompactIntegerSequence·p0.9999
              sample        62.000          ns/op
     [java] 
CompactIntegerSequenceBench.benchCompactIntegerSequence:benchCompactIntegerSequence·p1.00
                sample        62.000          ns/op
     [java] CompactIntegerSequenceBench.benchCompactSummingntegerSequence       
                                     sample    2  147.000          ns/op
     [java] 
CompactIntegerSequenceBench.benchCompactSummingntegerSequence:benchCompactSummingntegerSequence·p0.00
    sample       146.000          ns/op
     [java] 
CompactIntegerSequenceBench.benchCompactSummingntegerSequence:benchCompactSummingntegerSequence·p0.50
    sample       147.000          ns/op
     [java] 
CompactIntegerSequenceBench.benchCompactSummingntegerSequence:benchCompactSummingntegerSequence·p0.90
    sample       148.000          ns/op
     [java] 
CompactIntegerSequenceBench.benchCompactSummingntegerSequence:benchCompactSummingntegerSequence·p0.95
    sample       148.000          ns/op
     [java] 
CompactIntegerSequenceBench.benchCompactSummingntegerSequence:benchCompactSummingntegerSequence·p0.99
    sample       148.000          ns/op
     [java] 
CompactIntegerSequenceBench.benchCompactSummingntegerSequence:benchCompactSummingntegerSequence·p0.999
   sample       148.000          ns/op
     [java] 
CompactIntegerSequenceBench.benchCompactSummingntegerSequence:benchCompactSummingntegerSequence·p0.9999
  sample       148.000          ns/op
     [java] 
CompactIntegerSequenceBench.benchCompactSummingntegerSequence:benchCompactSummingntegerSequence·p1.00
    sample       148.000          ns/op
     [java] CompactIntegerSequenceBench.benchMemory                             
                                     sample    2   49.500          ns/op
     [java] CompactIntegerSequenceBench.benchMemory:benchMemory·p0.00           
                                     sample        44.000          ns/op
     [java] CompactIntegerSequenceBench.benchMemory:benchMemory·p0.50           
                                     sample        49.500          ns/op
     [java] CompactIntegerSequenceBench.benchMemory:benchMemory·p0.90           
                                     sample        55.000          ns/op
     [java] CompactIntegerSequenceBench.benchMemory:benchMemory·p0.95           
                                     sample        55.000          ns/op
     [java] CompactIntegerSequenceBench.benchMemory:benchMemory·p0.99           
                                     sample        55.000          ns/op
     [java] CompactIntegerSequenceBench.benchMemory:benchMemory·p0.999          
                                     sample        55.000          ns/op
     [java] CompactIntegerSequenceBench.benchMemory:benchMemory·p0.9999         
                                     sample        55.000          ns/op
     [java] CompactIntegerSequenceBench.benchMemory:benchMemory·p1.00           
                                     sample        55.000          ns/op
{noformat}

> Lower default chunk_length_in_kb from 64kb to 4kb
> -------------------------------------------------
>
>                 Key: CASSANDRA-13241
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13241
>             Project: Cassandra
>          Issue Type: Wish
>          Components: Core
>            Reporter: Benjamin Roth
>            Assignee: Ariel Weisberg
>            Priority: Major
>         Attachments: CompactIntegerSequence.java, 
> CompactIntegerSequenceBench.java, CompactSummingIntegerSequence.java
>
>
> Having a too low chunk size may result in some wasted disk space. A too high 
> chunk size may lead to massive overreads and may have a critical impact on 
> overall system performance.
> In my case, the default chunk size lead to peak read IOs of up to 1GB/s and 
> avg reads of 200MB/s. After lowering chunksize (of course aligned with read 
> ahead), the avg read IO went below 20 MB/s, rather 10-15MB/s.
> The risk of (physical) overreads is increasing with lower (page cache size) / 
> (total data size) ratio.
> High chunk sizes are mostly appropriate for bigger payloads pre request but 
> if the model consists rather of small rows or small resultsets, the read 
> overhead with 64kb chunk size is insanely high. This applies for example for 
> (small) skinny rows.
> Please also see here:
> https://groups.google.com/forum/#!topic/scylladb-dev/j_qXSP-6-gY
> To give you some insights what a difference it can make (460GB data, 128GB 
> RAM):
> - Latency of a quite large CF: https://cl.ly/1r3e0W0S393L
> - Disk throughput: https://cl.ly/2a0Z250S1M3c
> - This shows, that the request distribution remained the same, so no "dynamic 
> snitch magic": https://cl.ly/3E0t1T1z2c0J



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

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to