Roland Weber wrote:
The problem I see is to get CPU time for sending requests and detecting
responses. We will always need some kind of background thread to do that.
NIO can help to reduce the number of background threads, but that in turn
reduces concurrency: the connections will compete for processing time
from the shared threads. That's why I think that there should be different
options:
* IO+many threads for best response times
* NIO+few threads for resource efficiency
This problem could be addressed by dynamic allocation of threads:
Start with one thread that handles connections with NIO. This is done in
a selector loop. Continuously measure the wait-time vs. the processing
time. If this ratio exceeds a certain limit for a long enough time then
spawn another processing thread. If the ratio is low enough for a long
enough time then reduce the amount of threads.
It's not so easy to implement probably, but if done well can make an
extremely scalable system.
Odi
--
[web] http://www.odi.ch/
[blog] http://www.odi.ch/weblog/
[pgp] key 0x81CF3416
finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
