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