On 12/18/11 9:33 AM, Zigor Salvador wrote:
Hi Emmanuel,
On 17 Dec 2011, at 21:14, Emmanuel Lecharny wrote:
What about using more IoProcessor instead ? Have you tried this approach ?If
so, what was the result ?
Well, I found this in the documentation of SimpleIoProcessorPool:
"Most current transport implementations use this pool internally to perform better
in a multi-core environment, and therefore, you won't need to use this pool directly
unless you are running multiple IoServices in the same JVM."
So I never gave it a try. Maybe if someone could point me to an example that
shows the right way to increase the number of IoProcessors, I could give it a
try.
If you use more than one Selector, what will happen is that the sessions
will be spread over all the selectors, which means it might scale
better, without having to use an executor higher in the chain (having an
executor induces some complex issues with the session/thread affinity,
like you may have one session being executed by more than one thread).
I don't know if it really impacts the performances though. Now, if your
application is really CPU intensive, then having an executor is the
guaranteed way to be able to process more sessions concurrently, except
that up to a point, if you already have reached 100%CPU, there is
nothing you can do to improve the performances :)
The only possible way to improve the throughput (not the performance)
would be to be able to determinate which message will concume CU, and
dedicate a pool of thread for them, and let the other messages being
processed by some other threads (assuming there is a upper limit of
thread you can create).
Bottom line : there is no rule here, it's all about tuning and
experimenting :)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
