agree, thanks for bringing this up. Let's fix it. Cheers, -Ian.
On Fri, Oct 5, 2018 at 10:46 PM Huxing Zhang <hux...@apache.org> wrote: > On Sun, Sep 30, 2018 at 4:09 PM KimmKing <kimmk...@apache.org> wrote: > > > > Hi, community. > > > > > > Dubbo user manzhizhen find a preformance bug in > dubbo-cluster/RoundRobinLoadBalance and discuss in Github Is > > https://github.com/apache/incubator-dubbo/issues/2578 > > > > > > Here I describe it shortly: > > 1. The new version RoundRobinLoadBalance algorithm use an iterator from > 0 to maxWeight: > > for (int i = 0; i < maxWeight; i++) { // this is the reason > > for (Map.Entry<Integer, IntegerWrapper> each : > invokerToWeightMap.entrySet()) { > > .... > > } > > } > > 2.If maxWeight is a number much more than 100, then this select method > will be executed so mush slowly. > > 3. When call it 1M times: maxWeight is 5000, then it need 60+ seconds; > maxWeight is 50000, then it need 10+ minutes. > > 4. And in a deep compare testing, RandomLoadBalance & > RoundRobinLoadBalance (in 2.5.3, but implement is wrong) need 100-200ms > while calling 1M times. > > 5. So we should Optimize RoundRobinLoadBalance to a new high-performance > algorithm implement, abandoning iterator from 0 to maxWeight. > > 6. Then gudegg submit a PR to Optimize RoundRobinLoadBalance correctly, > the balance results by new PR is absolutely correct and only elapse > 100-300ms in my test like step 3. > > > > > > Think it above over and over, I suggest we should merge the PR recently. > > Any questions, buddies? > > +1 I've left some comments in the pull request. > > > > > > > > > > -- > > Kimm King(kimmk...@apache.org/kimmk...@163.com) > > Apache Dubbo Committer/Alibaba Fastjson Developer/Aliyun MVP > > > > > -- > Best Regards！ > Huxing >
