Hi, Thanks for inputs Sandeep, would take care of those points.
Here is high level design we are considering, We would have following components: *1.* *BandwidthManager* This keeps track of current bandwidth usage of system and takes decision if requested data bandwidth can be used right away or not. To do this it used Leaky bucket <https://en.wikipedia.org/wiki/Leaky_bucket> algorithm where it emits data as long as it has not overused bandwidth (i.e. bandwidth consumption is >=0) and then wait to accumulate bandwidth for a while (till bandwidth goes from -ve value to +ve). *2. BandwidthLimitingInputOperator* Any Input operator which want to implement bandwidth restriction should implement BandwidthLimitingInputOperator. The operator have abstract method to initialize instance of BandwidthManager and a method to emit tuple with bandwidth restriction to emit tuples as per available bandwidth. *3. BandwidthPartitioner* Bandwidth partitioner is introduced for static partitioning. If static partitioning is used by default StatelessPartitioner class is initialized. With bandwidth restriction we want to equally divide bandwidth amongst available partitions. BandwidthPartitioner should take care of it. It extends StatelessPartitioner, it just sets right bandwidth on all partitions after StatelessPartitioner creates/deletes partitiolns. In case of dynamic partitioning the operator implementing definePartitions, should take care of bandwidth distribution. This design takes care of basic bandwidth restriction, also takes care of partitions by equally distributing available bandwidth among all partitions. Also this is open enough to do further modifications to take care of complex situations. Let me know your opinion on what else we can do to design it better. -Priyanka On Thu, Mar 3, 2016 at 10:11 AM, Sandeep Deshmukh <[email protected]> wrote: > The main purpose is not to handle back pressure but to limit bandwidth > usage by applications. This is useful in ingestion use cases. Typically > user needs to ingest say up to 1GB per sec and not more. The tuple size > may vary based on messages based tuples (few KBs) or block tuples for files > (few MBs). Bandwidth manager will take max bandwidth that can be utilized > by the application and will take care of sharing that across partitions > etc. > > Priyanka: You could also consider following in your design > > 1. Limiting input rate (across partitions) > 2. Limiting output rate (across partitions) > 3. Specifying total bandwidth that the Application can utilize including > input and output? Not sure if this is required. Need comments from > others > here. > 4. Include default implementation that will handle 1 and 2, and anyone > interested in having their own Bandwidth manager should be able to > extend > the default one. > 5. Can you also look at including/extending tuples per sec as pointed > out by Tim/Chinmay. > > Regards, > Sandeep > > On Thu, Mar 3, 2016 at 12:23 AM, Timothy Farkas <[email protected]> > wrote: > > > Not sure if this is helpful, but there is already a utility in Malhar for > > converting tuples per second to tuples per window. This allows the user > to > > define a property in tuples per second, then the operator can convert > that > > to tuples per window so it emits the correct number of tuples per window. > > > > > > > https://github.com/apache/incubator-apex-malhar/blob/master/library/src/main/java/com/datatorrent/lib/util/time/WindowUtils.java > > > > On Wed, Mar 2, 2016 at 10:41 AM, Chinmay Kolhatkar < > > [email protected]> > > wrote: > > > > > Hi Priyanka, > > > > > > Indeed this is a useful feature. > > > > > > I believe number bytes consumed per sec can as well translate to number > > of > > > tuples consumed per sec. > > > > > > If above is correct, won't back pressure that is handled by > bufferserver > > > help in your use case? > > > > > > Thanks, > > > Chinmay. > > > On 2 Mar 2016 4:49 p.m., "Priyanka Gugale" <[email protected]> > > > wrote: > > > > > > > Many times we need to put bandwidth restrictions or put some limit on > > > input > > > > operator for number of bytes to be consumed per second. As I > understand > > > in > > > > Apex there is no direct support for this feature. > > > > > > > > I am planning to write a bandwidth manager which will help in > limiting > > > > bandwidth at Input operator. Let me know if there are any better > > > > alternative ways. I will soon publish design for Bandwidth Manager I > am > > > > planning to write. > > > > > > > > -Priyanka > > > > > > > > > >
