Hi, we have made the Disruptor optional and Samiyuru will continue on the testing as well.
thanks On Fri, Mar 11, 2016 at 12:08 PM, Isuru Ranawaka <isu...@wso2.com> wrote: > Hi Azeez, > > I am currently working on making disruptor optional and I will finish it > by EOD today.After that we will do the tests that kasun has mentioned and > figured out the best thread model for MSF4j to be used. > > thanks > > On Fri, Mar 11, 2016 at 12:00 PM, Afkham Azeez <az...@wso2.com> wrote: > >> Shall we aim to get to the bottom of this by EoD today? >> >> On Fri, Mar 11, 2016 at 11:44 AM, Samiyuru Senarathne <samiy...@wso2.com> >> wrote: >> >>> Transport config used for the above JFR: >>> - >>> id: "jaxrs-http" >>> host: "0.0.0.0" >>> port: 8080 >>> bossThreadPoolSize: 1 >>> workerThreadPoolSize: 16 >>> parameters: >>> # - >>> # name: "execThreadPoolSize" >>> # value: 2048 >>> - >>> name: "disruptor.buffer.size" >>> value: 1024 >>> - >>> name: "disruptor.count" >>> value: 5 >>> - >>> name: "disruptor.eventhandler.count" >>> value: 256 >>> # - >>> # name: "disruptor.wait.strategy" >>> # value: "SLEEP_WAITING" >>> - >>> name: "share.disruptor.with.outbound" >>> value: false >>> - >>> name: "disruptor.consumer.external.worker.pool.size" >>> value: 256 >>> >>> >>> On Fri, Mar 11, 2016 at 11:41 AM, Samiyuru Senarathne <samiy...@wso2.com >>> > wrote: >>> >>>> Please find the attached JFR dump of MSF4J-carbon-message-disruptor >>>> test performed with following 'ab' config. >>>> An MSF4J service that 'consumes a 1KB and sleeps for 50ms before >>>> responding the same 1KB' is used as the service. >>>> >>>> ab -k -p 1kb_rand_data.txt -s 999 -c 400 -n 5000 -H "Accept:text/plain" >>>> http://204.13.85.2:8080/EchoService/echo >>>> >>>> AB Results Summary: >>>> Concurrency Level: 400 >>>> Time taken for tests: 30.224 seconds >>>> Complete requests: 3000 >>>> Failed requests: 0 >>>> Keep-Alive requests: 3000 >>>> Total transferred: 3345000 bytes >>>> Total body sent: 3609000 >>>> HTML transferred: 3072000 bytes >>>> Requests per second: 99.26 [#/sec] (mean) >>>> Time per request: 4029.882 [ms] (mean) >>>> Time per request: 10.075 [ms] (mean, across all concurrent >>>> requests) >>>> Transfer rate: 108.08 [Kbytes/sec] received >>>> 116.61 kb/s sent >>>> 224.69 kb/s total >>>> >>>> >>>> >>>> On Fri, Mar 11, 2016 at 10:39 AM, Samiyuru Senarathne < >>>> samiy...@wso2.com> wrote: >>>> >>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Samiyuru Senarathne >>>> *Software Engineer* >>>> Mobile : +94 (0) 71 134 6087 >>>> samiy...@wso2.com >>>> >>> >>> >>> >>> -- >>> Samiyuru Senarathne >>> *Software Engineer* >>> Mobile : +94 (0) 71 134 6087 >>> samiy...@wso2.com >>> >> >> >> >> -- >> *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* >> > > > > -- > Best Regards > Isuru Ranawaka > M: +94714629880 > Blog : http://isurur.blogspot.com/ > -- Best Regards Isuru Ranawaka M: +94714629880 Blog : http://isurur.blogspot.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
