How do the RT changes in 2.5.x improve JVM performance? What numbers are people seeing? With asynchronous multiplexed IO support in 1.4 how do these simple param tweaks effect performance? Are we seeing much better response times due to busy waiting on selectors? Are there other issues? If there are, what are they and how can we design Java code around (for) them?
It seems to me that as people start to design more applications in Java, they will need to discuss issues such as these. With some of the NIO capabilities in 1.4, some people have suggested pure Java production databases, RT messaging systems, etc. I for one want to know that there is an issue with the Linux scheduler and how to fix it, if waiting 10ms to send my JMS message is just too long then the pros and cons of tweaking the kernel should be discussed.
-Jim
Generally better responsiveness is caused by a higher chance that
scheduler will sonner finish schedule interactive jobs - because time
quantums are 10 times smaller thus especially CPU hangry applications
like jave will see benefit of this as long computationaly intensive
threads will be more frequently interrupted by small interactive tasks.
The problem is that current linux scheduler is not optimal
(2.5.X kernels now has O(1) scheduler and some realtime patches which
should improve throughput of the system)
But as I said most probably this is not discussion which should be
on this list.
--
.''`. Which fundamental human right do you want to give up today?
: :' : Debian GNU/Linux maintainer - www.debian.{org,cz}
`. `' Zdenek Kabelac kabi@{debian.org, users.sf.net, fi.muni.cz}
`- When in doubt, just blame the Euro. :)
