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.
|Assignee||Willem Jiang [ njiang ]|
|Status||Open [ 1 ]||Resolved [ 5 ]|
|Fix Version/s||2.8.2 [ 12317866 ]|
|Fix Version/s||2.9.0 [ 12316374 ]|
|Resolution||Fixed [ 1 ]|
|Transition||Time In Source Status||Execution Times||Last Executer||Last Execution Date|
|14d 17h 35m||1||Willem Jiang||24/Oct/11 09:05|