Shall we aim to get to the bottom of this by EoD today? On Fri, Mar 11, 2016 at 11:44 AM, Samiyuru Senarathne <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> wrote: >>> >>>> I think Samiyuru tested with that nrw worker pool & still the >>>> performance is unacceptable. >>>> On Mar 11, 2016 9:45 AM, "Isuru Ranawaka" <[email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> 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: **[email protected]* <[email protected]> >>>>>>> * 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 >>> [email protected] >>> >> >> >> >> -- >> Samiyuru Senarathne >> *Software Engineer* >> Mobile : +94 (0) 71 134 6087 >> [email protected] >> > > > > -- > Samiyuru Senarathne > *Software Engineer* > Mobile : +94 (0) 71 134 6087 > [email protected] > -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * <http://www.apache.org/>* *email: **[email protected]* <[email protected]> * cell: +94 77 3320919blog: **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*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
