[
https://issues.apache.org/jira/browse/CASSANDRA-14097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280402#comment-16280402
]
Eric Evans commented on CASSANDRA-14097:
----------------------------------------
bq. CASSANDRA-12229 started down the road of implementing concurrency in
streaming. What specific things are you thinking about?
Thanks [~jasobrown], I wasn't aware of CASSANDRA-12229 (or the issues it
references)!
Mainly, I'm thinking to avoid the scenario where available throughput is a
function of how many nodes you're streaming from. If for example you have 3
nodes in 3 racks (1 node per rack), the bootstrap of an additional node will
stream everything from just one other node (from whichever node it shares a
rack with). Throughput can be very low as a result (particularly if
compression is in use); In our environment, I seldom see more than 36Mbps per
stream.
CASSANDRA-4663 would solve this for me (because I have many keyspaces), but
changing this from a function of "how many nodes" to "how many nodes and
keyspaces", still seems less than ideal.
> Per-node stream concurrency
> ---------------------------
>
> Key: CASSANDRA-14097
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14097
> Project: Cassandra
> Issue Type: Improvement
> Components: Streaming and Messaging
> Reporter: Eric Evans
>
> Stream sessions with a remote are bound to a single thread, and when
> compression is in use this thread can be CPU bound, limiting throughput
> considerably. When the number of nodes is small (i.e. when the number of
> concurrent sessions is also low), rebuilds or bootstrap operations can take a
> very long time.
> Ideally, data could be streamed from any given remote concurrently.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
