On Thu, Mar 10, 2016 at 10:26 AM, Afkham Azeez <az...@wso2.com> wrote:
> No from day 1, we have decided that GW & MSF4J will use the same Netty > transport component so that the config file will be the same as well as > improvements made to that transport will be automatically available for > both products. So now at least for MSF4J, we have issues in using the Netty > transport in its current state, so we have to fix those issues. > Reuse of same config files and components provide an advantage to us as the F/W developers/maintainers but my question was what are the benefits grant to end users of MSF4J through Carbon transport ? I don't think we can compromise performance numbers for a reason that is more important for F/W maintainers than end users, IMHO if we continue to use Carbon transport at least it should perform as same level as vanilla Netty. Can't we keep Disruptor while improve performance of Carbon transport ? Thanks ! > > On Thu, Mar 10, 2016 at 10:22 AM, Sagara Gunathunga <sag...@wso2.com> > wrote: > >> >> When we discuss last week about Carbon transports for MSF4J the main >> rational we identified was moving to Carbon transport will decouple >> transport threads from worker threads through Disruptor and provide lot of >> flexibility and manageability. If disruptor can't give better performance >> we should skip it no argument about that, but once we skip the disruptor >> the rational we made last week about thread pool decoupling become invalid >> if so why MSF4J should depend on Carbon transport ? If Carbon transport >> can't provide real advantages shouldn't MSF4J depend on vanilla Netty >> transports and make thing more lightweight ? >> >> Thanks ! >> >> On Thu, Mar 10, 2016 at 9:50 AM, Afkham Azeez <az...@wso2.com> wrote: >> >>> We need to do this fast because this task has taken close to 3 weeks now. >>> >>> 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/ >>>> >>> >>> >>> >>> -- >>> *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* >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Sagara Gunathunga >> >> Architect; WSO2, Inc.; http://wso2.com >> V.P Apache Web Services; http://ws.apache.org/ >> Linkedin; http://www.linkedin.com/in/ssagara >> Blog ; http://ssagara.blogspot.com >> >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *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* > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Sagara Gunathunga Architect; WSO2, Inc.; http://wso2.com V.P Apache Web Services; http://ws.apache.org/ Linkedin; http://www.linkedin.com/in/ssagara Blog ; http://ssagara.blogspot.com
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
