[ https://issues.apache.org/jira/browse/CASSANDRA-8457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14256293#comment-14256293 ]
Ariel Weisberg commented on CASSANDRA-8457: ------------------------------------------- Testing on AWS with 6 client and 9 servers. c3.8xlarge running Ubuntu 12.04 and no placement groups. I changed the workload to run RF=5 with the same data set size and increased the number of operations so the test runs longer. All tests were run on the same set of instances without restarting the instances. Numbers for trunk are all over the map and range from fantastically faster to slower. The modified version was more consistent but slower. When trunk was faster it had better CPU utilization. There is a correlation between low CPU utilization (not 1600% on a 16 core 32 thread server) and lower throughput. It kind of suggests there is some kind of starvation or contention preventing tasks from flowing. ||Run|Trunk|Modified|| |#1| 147925|119058| |#2|101740| 139155| |#3| 197265|147973| |#4|105774|#| Trunk performance is not ideal if only from a consistency perspective. I am going to try and get the performance counters for cache misses and such from perf as well as a profile tomorrow. > 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)