[
https://issues.apache.org/jira/browse/CASSANDRA-11351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194172#comment-15194172
]
Jason Brown commented on CASSANDRA-11351:
-----------------------------------------
I think this makes sense. The sending node can throttle itself as needed
(perhaps using existing mechanisms), and having the recipient indicate the max
throughput it will allow from each peer should better tune things. It might be
interesting for the recipient to send updates, as needed, to the senders based
on it's changing circumstances (some streams are complete, other have begun,
and so on). For example, if streaming from 10 peers, after some subset of
streams have finished, the recipient could send a message to the remaining
senders and tell them it can now accept more Mb/s.
> rethink stream throttling logic
> -------------------------------
>
> Key: CASSANDRA-11351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11351
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Brandon Williams
>
> Currently, we throttle steaming from the outbound side, because throttling
> from the inbound side is thought as not doable. This creates a problem
> because the total stream throughput is based on the number of nodes involved,
> so based on the operation to be performed it can vary. This creates
> operational overhead, as the throttle has to be constantly adjusted.
> I propose we flip this logic on its head, and instead limit the total inbound
> throughput. How? It's simple: we ask. Given a total inbound throughput of
> 200Mb, if a node is going to stream from 10 nodes, it would simply tell the
> source nodes to only stream at 20Mb/s when asking for the stream, thereby
> never going over the 200Mb inbound limit.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
