[
https://issues.apache.org/jira/browse/CASSANDRA-9766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15267533#comment-15267533
]
Benedict commented on CASSANDRA-9766:
-------------------------------------
It certainly was the intention that the FastThreadLocal be used by C* back when
I wrote it, although my intention had been to move it in-tree to maintain
ourselves as our goals are a bit different to Netty's. The Recycler is a good
example - it's designed to permit low overhead but _concurrent_ recycling, with
some guarantees about not behaving badly in the face of user misuse. This is
probably overkill for our use case, but it is somewhat general purpose and
those guarantees might well be nice. I have no strong opinion.
On the topic of BTreeSearchIterator: In 3.0, for most users the
BTreeSearchIterator is likely to be a single very small object, and even for
large partitions it will still be a very small number. I would be surprised if
recycling such small objects can easily be made a win, but if they really have
such a large heap impact having a truly thread local queue with a small maximum
number of elements per thread would be the only way to get close to
non-recycled performance.
Reusing the Object[] for our builders is definitely a good thing to do though.
Disclaimer: I have not read the patch.
> Bootstrap outgoing streaming speeds are much slower than during repair
> ----------------------------------------------------------------------
>
> Key: CASSANDRA-9766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9766
> Project: Cassandra
> Issue Type: Improvement
> Components: Streaming and Messaging
> Environment: Cassandra 2.1.2. more details in the pdf attached
> Reporter: Alexei K
> Assignee: T Jake Luciani
> Labels: performance
> Fix For: 3.x
>
> Attachments: problem.pdf
>
>
> I have a cluster in Amazon cloud , its described in detail in the attachment.
> What I've noticed is that we during bootstrap we never go above 12MB/sec
> transmission speeds and also those speeds flat line almost like we're hitting
> some sort of a limit ( this remains true for other tests that I've ran)
> however during the repair we see much higher,variable sending rates. I've
> provided network charts in the attachment as well . Is there an explanation
> for this? Is something wrong with my configuration, or is it a possible bug?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
