Hi, Please find results of the tests I have done so far. https://docs.google.com/a/wso2.com/spreadsheets/d/16TXeXU022b5ILqkRsY3zZdnu2OiA3yWEN42xVL8eXa4/edit?usp=sharing
MSF4J 1.0.0 section of this tests gives a good insight into the netty thread behaviour. I focused a bit more on that because confirming the practical behaviour of netty thread model is one of the first things we should do. According to these results, - Increasing the netty boss pool does not make any difference. - For the netty worker pool, it's enough to have a number of threads equal to the number of cpus. - Increasing the number of threads of the pool of the netty handler that does the actual work increases the performance significantly for high concurrency levels. Regarding the tests that include disruptor, I applied the optimal configurations according to [1]. But I could not get results even close to the results of GW and the results I got are bit strange (99 TPS regardless of concurrency level). I think we should try more variations of disruptor settings before coming to a conclusion. [1] - https://docs.google.com/a/wso2.com/spreadsheets/d/1ck2O7eMkswJSQCgW8ciOkIyZkXGiZhIxRWNN-R9vgMk/edit?usp=sharing Best Regards, Samiyuru On Fri, Mar 11, 2016 at 10:06 AM, Afkham Azeez <az...@wso2.com> wrote: > I think Samiyuru tested with that nrw worker pool & still the performance > is unacceptable. > On Mar 11, 2016 9:45 AM, "Isuru Ranawaka" <isu...@wso2.com> wrote: > >> Hi , >> >> We have already added native worker pool for Disruptor and Samiyuru is >> doing testing on that. We will make disruptor optional as well. >> >> thanks >> >> On Thu, Mar 10, 2016 at 9:29 AM, Kasun Indrasiri <ka...@wso2.com> wrote: >> >>> Yes, we can make the disruptor optional. Also, we should try using the >>> native worker pool for Event Handler[1], so that the Disruptor itself runs >>> the event handler on a worker pool. We'll implement both approaches and do >>> a comparison. >>> >>> [1] >>> https://lmax-exchange.github.io/disruptor/docs/com/lmax/disruptor/dsl/Disruptor.html#handleEventsWithWorkerPool(com.lmax.disruptor.WorkHandler.. >>> .) >>> >>> On Thu, Mar 10, 2016 at 8:48 AM, Afkham Azeez <az...@wso2.com> wrote: >>> >>>> After upgrading to the new transport, we are seeing a significant drop >>>> in performance for any service that take some time to execute. We have >>>> tried with the configuration used for the gateway which gave the best >>>> figures on the same hardware. We have also noted that using a separate >>>> dedicated executor thread pool, which is supported by Netty, gave much >>>> better performance than the disruptor based implementation. Even in theory, >>>> disruptor cannot give better performance when used with a real service that >>>> does some real work, rather than doing passthrough, for example. Can we >>>> improve the Netty transport to make going through disruptor optional? >>>> >>>> -- >>>> *Afkham Azeez* >>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>> Member; Apache Software Foundation; http://www.apache.org/ >>>> * <http://www.apache.org/>* >>>> *email: **az...@wso2.com* <az...@wso2.com> >>>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * >>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>> *twitter: **http://twitter.com/afkham_azeez* >>>> <http://twitter.com/afkham_azeez> >>>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>> >>>> *Lean . Enterprise . Middleware* >>>> >>> >>> >>> >>> -- >>> Kasun Indrasiri >>> Software Architect >>> WSO2, Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> cell: +94 77 556 5206 >>> Blog : http://kasunpanorama.blogspot.com/ >>> >> >> >> >> -- >> Best Regards >> Isuru Ranawaka >> M: +94714629880 >> Blog : http://isurur.blogspot.com/ >> > -- Samiyuru Senarathne *Software Engineer* Mobile : +94 (0) 71 134 6087 samiy...@wso2.com
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
