[
https://issues.apache.org/jira/browse/CAMEL-4531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edge wang updated CAMEL-4531:
-----------------------------
Attachment: workerCount.patch
> Expose workerCount parameter of Netty NioServerSocketChannelFactory in
> Camel-Netty
> ----------------------------------------------------------------------------------
>
> Key: CAMEL-4531
> URL: https://issues.apache.org/jira/browse/CAMEL-4531
> Project: Camel
> Issue Type: Improvement
> Components: camel-netty
> Affects Versions: 2.8.1
> Environment: ALL
> Reporter: edge wang
> Attachments: workerCount.patch
>
>
> Camel-netty component did not implement oio model of netty, we can only use
> nio one, however it uses default workerCount parameter from Netty, which is
> cpu_core_threads*2.
> This is far from enough when the underlying app is a little bit slow, e.g. a
> traditional transactional application. In this situation NioWorker threads
> become an obvious bottle neck.
> I think that exposing workerCount is a very practical yet effective way for
> one to broaden the usage scenario of camel-netty in various network
> communication/application environment.
> I add a workerCount parameter in the configuration, one can use it in the
> Endpoint URL: "netty:tcp://0.0.0.0:1111?...&workerCount=256&...". I leave the
> default value to 0 so that one can use Netty default policy by omit the param.
> I have tested the patch in a 2 core(4 Threads) machine, using 256 workers, it
> significantly improves the performance by 15 times, than the default
> parameter of only 8 workers, while CPU usage only increase 5 times.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
