[concurrency-interest] Benchmark to demonstrate improvement in thread management over the years.
stanimir at riflexo.com
Tue Aug 13 04:29:36 EDT 2013
The main benefit of the NIO is the lower AND predictable latency per
client. You may apply your own policy, order and priority.
The paper mentions nothing about latency and you are at mercy of the OS
scheduler to serve your clients properly. Thread.setPriority virtually
doesn't work, so everything has equal priority but the OS may boost some
threads if they feel so.
For some applications that might not be critical, of course...
Actually, 1000 I/O bound threads on modern hardware is probably low load.
On Mon, Aug 12, 2013 at 5:06 PM, Oleksandr Otenko <
oleksandr.otenko at oracle.com> wrote:
> On 12/08/2013 14:03, Unmesh Joshi wrote:
> Most of the books on node.js, Akka, Play or any other event IO based
> system frequently talk about 'Threads' being heavy and there is cost we
> have to pay for all the booking the OS or the JVM has to do with all the
> While I agree that there must be some cost and for doing CPU intensive
> tasks like matrix multiplication, and fork-join kind of framework will be
> more performant, I am not sure if for web server kind of IO intensive
> application that's the case.
> On the contrary, I am seeing web servers running on tomcat with 1000 +
> threads without issues. For web servers. I think that Linux level thread
> management has improved a lot in last 10 years. Same is with the JVM.
> Do we have any benchmark which shows how much Linux thread management
> and JVM thread management have improved over the years?
> Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest