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/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
