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

David Capwell commented on CASSANDRA-16036:
-------------------------------------------

Here are the results I am seeing (baseline is 3.0); all read only tests are 
expected to have zero compaction going on, the cluster only ran the specific 
workload at the time, multi workload traffic has not happened.

* Point reads show roughly equal performance
* Scans around 99.5% we see cache doing better but under that non cache is 
better
* In clause shows improvement with cache

>From past testing, anything greater than 99.99% is too noisy to really look 
>at, so ignoring that when making my statements.  Given this the only test out 
>of the 4 that had any benefit was the in-clause test (will run a few more 
>times to see how stable), and the scan tests were generally regressed.  The 
>tests which were designed to highlight this feature (medium blob, and 
>Partition single row read) showed no difference with or without the cache.

In my experience, in clause is rather rare but scans are much more common 
(partition read, read range by clustering, read latest N rows, etc.).  If 
compaction is constantly running (unlikely in these tests, much more likely in 
production) then the cache is invalidated very frequently which should yield 
worse results than what these tests show (homogeneous query pattern vs 
heterogeneous query pattern); given this I am still in favor of the default of 
false.

[~jmeredithco] can you review again?  [~jasonstack] can I get your feedback as 
well?

> Add flag to disable chunk cache and disable by default
> ------------------------------------------------------
>
>                 Key: CASSANDRA-16036
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-16036
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Legacy/Local Write-Read Paths
>            Reporter: David Capwell
>            Assignee: David Capwell
>            Priority: Normal
>             Fix For: 4.0-beta
>
>         Attachments: clustering-in-clause_latency_selects_baseline.png, 
> clustering-in-clause_latency_under90_selects_baseline.png, 
> clustering-slice_latency_selects_baseline.png, 
> clustering-slice_latency_under90_selects_baseline.png, 
> medium-blobs_latency_selects_baseline.png, 
> medium-blobs_latency_under90_selects_baseline.png, 
> partition-single-row-read_latency_selects_baseline.png, 
> partition-single-row-read_latency_under90_selects_baseline.png
>
>
> Chunk cache is enabled by default and doesn’t have a flag to disable without 
> impacting networking.  In performance testing 4.0 against 3.0 I found that 
> reads were slower in 4.0 and after profiling found that the ChunkCache was 
> partially to blame; after disabling the chunk cache, read performance had 
> improved.
> {code}
> 40_w_cc-selects.hdr
> #[Mean    =     11.50063, StdDeviation   =     13.44014]
> #[Max     =    482.41254, Total count    =       316477]
> #[Buckets =           25, SubBuckets     =       262144]
> 40_wo_cc-selects.hdr
> #[Mean    =      9.82115, StdDeviation   =     10.14270]
> #[Max     =    522.36493, Total count    =       317444]
> #[Buckets =           25, SubBuckets     =       262144]
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

Reply via email to