> Please do not use > the 0.6 as the overload threshold - with 80 threads that leaves only 12 > for the node to process requests and new connections, which is far too > little.
Bit of a dumbass question - what do all the threads actually *do*? As in, what are the specific tasks that a thread does? Are all threads created equal or are some created to do something specific - once a thread has been removed from the idle pool does it 'do one thing' before being returned to the idle pool or can it change role without being idled and unidled? If the only reason for having so many threads is to prevent IO blocking then we really ought to use asynchronous IO. Since I don't know Java I don't know how realistic this is but obviously it must be an issue because other people have been talking about it and apparently we still aren't using it. My guess is, assuming the JVM supports asynchronous IO calls at all, that the IO scheduling is handled almost entirely by the OS not the JVM, whereas synchronous IO calls not only require more OS resources but also more JVM resources too, simply because of the number of threads required. If fred could use asynchronous IO, assuming JVM support, how many threads would be necessary? Like, three or four rather than a hundred? Or are all the additional threads used just to service the computational aspects of request and response, such as encryption, fec, etc? d _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
