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