cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Brown (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11351) rethink stream throttling logic
Date Mon, 14 Mar 2016 21:27:33 GMT


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

View raw message