cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ariel Weisberg (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8457) nio MessagingService
Date Mon, 22 Dec 2014 23:09:13 GMT


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.

|#1| 147925|119058|
|#2|101740| 139155|
|#3| 197265|147973|

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:
>             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

View raw message