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

Stefania commented on CASSANDRA-12269:
--------------------------------------

bq. This would mean we have to try catch every call vs just the ones that throw 
checked exceptions. 

No, we could have instantiated the call with RuntimeException as well as 
IOException. Nevermind though, if you are happy with WrappedException let's 
keep it, especially now that we have other wrapped classes anyway.

bq. ant microbench -Dbenchmark.name=MutationBench

Thanks, I has to do a realclean but it works now.

bq. The problem is none of these work with native types like int and boolean. 
So unless I'm missing something the wrapper approach is what I went with.

That's true, the only way to avoid the wrapped classes is to implement the 
lambda interface in a non-anonymous class, which is heavy, so let's go with the 
wrapped classes. Did you mean to keep {{Wrapped<T>}} even if it's not used?

Some more nits:

* Unused imports 
[here|https://github.com/apache/cassandra/compare/trunk...tjake:write-perf#diff-75146ba408a51071a0b19ffdfbb2bb3cR35],
 
[here|https://github.com/apache/cassandra/compare/trunk...tjake:write-perf#diff-8336374a213ec8c7a6feca884793208eR30]
 and 
[here|https://github.com/apache/cassandra/compare/trunk...tjake:write-perf#diff-aa58d440e494ef966bf05abf4f6a9e61R26]
* The comment at [this 
line|https://github.com/apache/cassandra/compare/trunk...tjake:write-perf#diff-75146ba408a51071a0b19ffdfbb2bb3cR302]
 is no longer relevant
* Indentation error 
[here|https://github.com/apache/cassandra/compare/trunk...tjake:write-perf#diff-aa58d440e494ef966bf05abf4f6a9e61R88]
* Typo 
[here|https://github.com/apache/cassandra/compare/trunk...tjake:write-perf#diff-4688f6b2ea84a0728a284ead1cf78adcR22]

Tests were aborted and it seems other jobs I launched in the last couple of 
hours also did, so I cannot restart them for you right now but hopefully you 
can restart them later and they'll work.

+1, subject to nits and clean test results, great work!

> Faster write path
> -----------------
>
>                 Key: CASSANDRA-12269
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-12269
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: T Jake Luciani
>            Assignee: T Jake Luciani
>             Fix For: 3.10
>
>
> The new storage engine (CASSANDRA-8099) has caused a regression in write 
> performance.  This ticket is to address it and bring 3.0 as close to 2.2 as 
> possible. There are four main reasons for this I've discovered after much 
> toil:
> 1.  The cost of calculating the size of a serialized row is higher now since 
> we no longer have the cell name and value managed as ByteBuffers as we did 
> pre-3.0.  That means we current re-serialize the row twice, once to calculate 
> the size and once to write the data.  This happens during the SSTable writes 
> and was addressed in CASSANDRA-9766.
>      Double serialization is also happening in CommitLog and the 
> MessagingService.  We need to apply the same techniques to these as we did to 
> the SSTable serialization.
> 2.  Even after fixing (1) there is still an issue with there being more GC 
> pressure and CPU usage in 3.0 due to the fact that we encode everything from 
> the {{Column}} to the {{Row}} to the {{Partition}} as a {{BTree}}.  
> Specifically, the {{BTreeSearchIterator}} is used for all iterator() methods. 
>  Both these classes are useful for efficient removal and searching of the 
> trees but in the case of SerDe we almost always want to simply walk the 
> entire tree forwards or reversed and apply a function to each element.  To 
> that end, we can use lambdas and do this without any extra classes.
> 3.  We use a lot of thread locals and check them constantly on the read/write 
> paths.  For client warnings, tracing, temp buffers, etc.  We should move all 
> thread locals to FastThreadLocals and threads to FastThreadLocalThreads.
> 4.  We changed the memtable flusher defaults in 3.2 that caused a regression 
> see: CASSANDRA-12228



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

Reply via email to