[ 
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)

Reply via email to