[jira] [Comment Edited] (CASSANDRA-8342) Remove historical guidance for concurrent reader and writer tunings.

2014-11-25 Thread Ryan McGuire (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-8342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14225427#comment-14225427
 ] 

Ryan McGuire edited comment on CASSANDRA-8342 at 11/25/14 11:57 PM:


http://riptano.github.io/cassandra_performance/graph_v4/graph.html?stats=stats.8342.json

Definitely agree that increasing it doesn't improve things, but not seeing much 
of a dropoff either.

Per Jonathan's suggestion, this test was with load smaller than memory. 
Rereading the guidance text in the yaml, it would seem to suggest testing this 
with a load larger?


was (Author: enigmacurry):
http://riptano.github.io/cassandra_performance/graph_v4/graph.html?stats=stats.8342.json

Definitely agree that increasing it doesn't improve things, but not seeing much 
of a dropoff either.

Per Jonathan's suggestion, this test was all in memory though. Rereading the 
guidance text in the yaml would seem to suggest testing this with a load 
larger, no?

 Remove historical guidance for concurrent reader and writer tunings.
 

 Key: CASSANDRA-8342
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8342
 Project: Cassandra
  Issue Type: Improvement
Reporter: Matt Stump
Assignee: Ryan McGuire

 The cassandra.yaml and documentation provide guidance on tuning concurrent 
 readers or concurrent writers to system resources (cores, spindles). Testing 
 performed by both myself and customers demonstrates no benefit for thread 
 pool sizes above 64 in size, and for thread pools greater than 128 in size a 
 decrease in throughput. This is due to thread scheduling and synchronization 
 bottlenecks within Cassandra. 
 Additionally, for lower end systems reducing these thread pools provides very 
 little benefit because the bottleneck is typically moved to either IO or CPU.
 I propose that we set the default value to 64 (current default is 32), and 
 remove all guidance/recommendations regarding tuning.
 This recommendation may change in 3.0, but that would require further 
 experimentation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (CASSANDRA-8342) Remove historical guidance for concurrent reader and writer tunings.

2014-11-25 Thread Ryan McGuire (JIRA)

[ 
https://issues.apache.org/jira/browse/CASSANDRA-8342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14225427#comment-14225427
 ] 

Ryan McGuire edited comment on CASSANDRA-8342 at 11/25/14 11:57 PM:


http://riptano.github.io/cassandra_performance/graph_v4/graph.html?stats=stats.8342.json

Definitely agree that increasing it doesn't improve things, but not seeing much 
of a dropoff either.

Per Jonathan's suggestion, this test was with load smaller than memory. 
Rereading the guidance text in the yaml, it would seem to suggest testing this 
with a load larger than memory?


was (Author: enigmacurry):
http://riptano.github.io/cassandra_performance/graph_v4/graph.html?stats=stats.8342.json

Definitely agree that increasing it doesn't improve things, but not seeing much 
of a dropoff either.

Per Jonathan's suggestion, this test was with load smaller than memory. 
Rereading the guidance text in the yaml, it would seem to suggest testing this 
with a load larger?

 Remove historical guidance for concurrent reader and writer tunings.
 

 Key: CASSANDRA-8342
 URL: https://issues.apache.org/jira/browse/CASSANDRA-8342
 Project: Cassandra
  Issue Type: Improvement
Reporter: Matt Stump
Assignee: Ryan McGuire

 The cassandra.yaml and documentation provide guidance on tuning concurrent 
 readers or concurrent writers to system resources (cores, spindles). Testing 
 performed by both myself and customers demonstrates no benefit for thread 
 pool sizes above 64 in size, and for thread pools greater than 128 in size a 
 decrease in throughput. This is due to thread scheduling and synchronization 
 bottlenecks within Cassandra. 
 Additionally, for lower end systems reducing these thread pools provides very 
 little benefit because the bottleneck is typically moved to either IO or CPU.
 I propose that we set the default value to 64 (current default is 32), and 
 remove all guidance/recommendations regarding tuning.
 This recommendation may change in 3.0, but that would require further 
 experimentation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)