On Wed, Mar 26, 2003 at 05:00:07AM -0500, Gianni Johansson wrote: > Matthew Toseland wrote: > >On Mon, Mar 24, 2003 at 10:34:48PM -0800, Tracy R Reed wrote: > > > >>On Tue, Mar 25, 2003 at 05:34:19AM -0500, Gianni Johansson spake thusly: > >> > >>>Has anyone definitively tracked down the source of the CPU load issue? > >>> > >>>If not, what are the best hypotheses? > >> > > > >Threads. Threads. Threads. And did I mention threads? > > > > What do you mean? Thread creation should be minimized by the thread pooling.
>I mean context switching. We have heard from other people who have used >java with very many threads, saying that the context switching overhead >is actually a big part of the slowness. Anyway, java provides various >profiling tools... if you set cpu=samples, you get timings including >idle time waiting for IO, but it's fast. If you set cpu=times, you get >actual CPU times... this should identify any bottlenecks. Last I looked >most of the top seemed to be dominated by crypto, but you are welcome to >try. I second this reasoning. I googled around for some hard facts about JVM context switching time but didn't find anything very good. However, the feeling that I got from various source was that thread context switching time in java seemed to be counted in milleseconds at least. When fred is running over 400 (or something) threads even my 1.7GHz p4 will feel sluggish and unresponsive, not because of actual work done according to the computer.. probably context switching I guess. /N _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
