Yes, Azeez. So we are currently testing following approaches, with some processing at the engine side (rather than doing just pass-thru).
- Transport with netty worker pool(IO) -> message processing worker pool which does the dispatching/processing of the messages : (No Disruptor/Making the disruptor optional) - Transport with Disruptor + Single event handler (GW's default thread model) : This is the model that gave us the best performance for the GW scenario(header based routing). - Transport with Disruptor + native worker pool for event handler. Based on the outcome of this, we can decide which thread model suits the best when it comes to msf4j like scenario and we can make it configurable at the transport side. 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/ >> > -- Kasun Indrasiri Software Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 77 556 5206 Blog : http://kasunpanorama.blogspot.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
