[
https://issues.apache.org/jira/browse/CASSANDRA-8457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14266963#comment-14266963
]
Ariel Weisberg commented on CASSANDRA-8457:
-------------------------------------------
I ran on GCE. 11 n1-highcpu-16, 2 clients 9 servers.
ubuntu-1404-trusty-v20141212
GCE distributes interrupts to all cores by default.
The conclusion is that on GCE at that cluster config coalescing provides some
benefit, although not to the extreme degree it was beneficial in EC2 without
enhanced networking. The window to coalesce in doesn't have to be large to get
the value. Binding interrupts to core 0 has a negative impact on throughput
that doesn't change depending on whether no delay is enabled/disabled, but
coalescing and binding yields the same similar throughput as distributing
interrupts and coalescing.
It's very much an apples to oranges comparison to the EC2 c3.8xlarge which is
much bigger instance (certainly in terms of RAM and exposed hardware threads)
and more likely to benefit from more packet throughput. They are also
completely different virtualization technologies and I guess it shows with
things like toggling no delay having no impact in GCE even though performing
the coalescing manually does.
Running with TCP no delay off
132254
132862
With TCP no delay on and coalescing
||Coalesce window microseconds| Throughput||
|200| 149791|
|150| 148755|
|100| 147678|
|50| 142565|
|25| 144542|
|12| 141679|
|6| 142626|
|0| 133905|
|0| 132849|
I then tested with all interrupts bound to core 0
With TCP no delay off
116157
No delay on, no coalescing
118134
No delay on, coalescing 200 microseconds
147257
146453
> 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)
