[
https://issues.apache.org/jira/browse/CASSANDRA-8457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14249678#comment-14249678
]
Benedict commented on CASSANDRA-8457:
-------------------------------------
A couple of comments on the code:
# Requiring synchronized seems _possible_ to negate any benefit, since we could
easily get more threads competing. Certainly the cost seems higher than what we
save from a lazySet; my typical strategy for this situation is to set the
wakeup flag to true, check if any more work needs to be done, and _if so_
atomically re-adopt the state. So the despatch task would be a a loop,
terminating only when there is definitely no work to do.
# If we're worrying about context switching, we should probably switch to CLQ
so that producers never conflict. If we're worried about less efficient
draining, we can later introduce a MPSC queue with an efficient drainTo().
# droppedUpdater.decrementAndGet() looks like a typo
However I doubt any of these will have a _significant_ impact.
The stress test you're running should exercise these pathways in a typical
manner. I'm not terribly surprised at a lack of impact, but it is probably
worth trying on a much larger cluster to see if more-often-empty queues and a
surfeit of threads can elicit a result.
> nio MessagingService
> --------------------
>
> Key: CASSANDRA-8457
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8457
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Ariel Weisberg
> Labels: performance
> Fix For: 3.0
>
>
> Thread-per-peer (actually two each incoming and outbound) is a big
> contributor to context switching, especially for larger clusters. Let's look
> at switching to nio, possibly via Netty.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
