[
https://issues.apache.org/jira/browse/STORM-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Zhong updated STORM-272:
-----------------------------
Description:
In my profiling, I found the receiver thread of worker can be a performance
bottle-neck.
Now each worker has single receiver thread, and it is responsbile to transfer
information generated from multiple netty client to tens of executor disruptor
queue. It is too much for busy topology.
Without this fix, we have to increase the number of workers, which will create
more intra-worker traffic that we don't want.
I suggest that we can add a config called "worker.receiver.thread.count" to
control the parallism of the receiver thread, and make it default to 1.
was:
In my profiling, I found the receiver thread of worker can be a performance
bottle-neck.
Now each worker has single receiver thread, and it is responsbile to transfer
information generated from multiple netty client to tens of executor disruptor
queue. It is too much for busy topology.
Without this fix, we have to increase the number of workers, which will create
more intra-worker traffic that we don't want.
> Make worker receiver thread number configurable
> -----------------------------------------------
>
> Key: STORM-272
> URL: https://issues.apache.org/jira/browse/STORM-272
> Project: Apache Storm (Incubating)
> Issue Type: Improvement
> Affects Versions: 0.9.2-incubating
> Reporter: Sean Zhong
> Priority: Minor
>
> In my profiling, I found the receiver thread of worker can be a performance
> bottle-neck.
> Now each worker has single receiver thread, and it is responsbile to transfer
> information generated from multiple netty client to tens of executor
> disruptor queue. It is too much for busy topology.
> Without this fix, we have to increase the number of workers, which will
> create more intra-worker traffic that we don't want.
>
> I suggest that we can add a config called "worker.receiver.thread.count" to
> control the parallism of the receiver thread, and make it default to 1.
--
This message was sent by Atlassian JIRA
(v6.2#6252)