While not a comment about this proposal I have a comment another split bundle concept.
Manually split out a topic into its own bundle. Say a bundle is 0x00000000 to 0x00000200 with 5 topics. t1 at 0x00000010 t2 at 0x00000030 t3 at 0x00000110 t4 at 0x00000123 t5 at 0x000001AE Let’s split out t3 to it’s own bundle and then have three new bundles: 0x00000000:0x0000010F - t1, t2 0x00000110:0x00000110 - t3 0x00000111:0x00000200 - t4, t5 This can be useful when t3 has most of the traffic > On Aug 23, 2022, at 2:13 AM, lordcheng10 <1572139...@qq.com.INVALID> wrote: > > "It's a good idea to improve the bundle split for the case that the traffic > of the topic doesn't change drastically > Otherwise, we should not use this policy. or can we use it for all cases?" > > > 1.It is suitable for scenarios where topic traffic is relatively stable. In > addition, we can also adjust the flowOrQpsDifferenceThresholdPercentage > configuration to adapt to traffic fluctuations; > 2.The current strategy is to split bundles based on the configuration > loadBalancerNamespaceBundleMaxMsgRate or > loadBalancerNamespaceBundleMaxBandwidthMbytes; > 3.If the qps or traffic of a bundle is less than > loadBalancerNamespaceBundleMaxMsgRate*(1+ > flowOrQpsDifferenceThresholdPercentage) or > loadBalancerNamespaceBundleMaxBandwidthMbytes*(1+flowOrQpsDifferenceThresholdPercentage), > the policy will no longer trigger split; > > > "do we need to consider the consumer rate > the `flow or qps` is based on the entries or messages?" > > > 1. The consumer rate has been considered; > 2. The strategy has been based on the entries and throughput; > > > > > Thanks, > lordcheng10 > > > Reply for Penghui
