Cant agree any more. No Bottlenecks, No Profiling. No Benchmarks, No Improvement.
At 2018-09-20 12:38:37, "Ian Luo" <ian....@gmail.com> wrote: >Profiling support is ready. We need some volunteers to use this benchmark >project to analyze the bottlenecks in Dubbo framework. > >On Wed, Sep 19, 2018 at 7:27 AM Huxing Zhang <hux...@apache.org> wrote: > >> On Mon, Sep 17, 2018 at 10:53 AM Ian Luo <ian....@gmail.com> wrote: >> > >> > Kirito, >> > >> > We need to understand where the bottlenecks are better before we do >> > performance tuning. What I suggest is we need to profile Dubbo first, and >> > this is the main purpose of dubbo-benchmark project [1]. >> >> Do we have any plan for the dubbo-benchmark project? >> >> > >> > You may also interested in reading this article [2]. It looks like >> > MethodParam he mentioned in this particle is a killer hack. >> > >> > Thanks, >> > -Ian. >> > >> > 1. https://github.com/dubbo/dubbo-benchmark >> > 2. https://www.jianshu.com/p/7182b8751e75 >> > >> > >> > >> > On Sun, Sep 16, 2018 at 8:21 PM YunKun Huang <hyun...@apache.org> wrote: >> > >> > > Protocol is not easy to change, there are many other client which base >> on >> > > the protocol. >> > > >> > > For the item 2 and item 6, it looks like a good start, since those >> change >> > > will not impact API. >> > > >> > > On 2018/09/15 04:19:31, kirito <kirito....@foxmail.com> wrote: >> > > > Hi,community >> > > > >> > > > I recently read some rpc-benchmark articles from the internet. And >> on 31 >> > > Jan 2018 someone submit a issue >> > > https://github.com/apache/incubator-dubbo/issues/1301 < >> > > https://github.com/apache/incubator-dubbo/issues/1301> which didn't >> > > attract too much attention. Here is his benchmark code >> > > https://github.com/hank-whu/rpc-benchmark < >> > > https://github.com/hank-whu/rpc-benchmark> . >> > > > >> > > > The simplest way you know the whole details is to read the blog >> written >> > > by him — https://www.jianshu.com/p/7182b8751e75 < >> > > https://www.jianshu.com/p/7182b8751e75> (English player may ask google >> > > translation for help, it was written in Chinese). >> > > > >> > > > Dubbo performs not very well. >> > > > >> > > > Here are some optimization I can notice about common rpc framework, >> in >> > > some aspects dubbo do well, but not all. >> > > > >> > > > 1. serialization >> > > > Kryo , Hession , FastJson >> > > > >> > > > 2. dynamic method invocation/ dynamic proxy >> > > > Reflect, ClassGeneration ,MethodHandle ,Cglib >> > > > >> > > > 3. protocol message format >> > > > According to the above blog, dubbo message looks too complex, too >> > > big to lose some performance. >> > > > >> > > > 4. transport >> > > > Netty is no doubt, but details also can consider, like zero-copy. >> > > > >> > > > 5. cache and reuse >> > > > Cache should be exist anywhere if it can. Pooled resources is a >> > > classic reuse plan. >> > > > >> > > > 6. High-performance data structure >> > > > I highly recommended to use JCTools,Disruptor to refactor some >> > > low-performance implementation. >> > > > I try to replace `Random` with `ThreadLocalRandom`.And I know >> that >> > > dubbo has used a faster ThreadLocal — FastThreadLocal from netty. We >> may >> > > discover more. >> > > > >> > > > 7. CPU trick, JVM optimization, and more other small point we can >> > > optimize >> > > > False sharing , care about CPU cache-line. >> > > > JVM method inline. >> > > > Method dispatch. >> > > > Branch predication. >> > > > MultiThreads. >> > > > JVM garbage collection. >> > > > And more >> > > > >> > > > >> > > > More optimization is recommend to discuss and we can issue/pull >> request >> > > to solve those low-performance problem in dubbo. >> > > > >> > > > xujingfeng(kirito) >> > > > >> > > > >> > > > >> > > > >> > > > >> > > >> >> >> >> -- >> Best Regards！ >> Huxing >>
