Hi Odi, thanks for the idea, I'll keep it in mind.
cheers, Roland Ortwin Glück wrote: > > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
