[concurrency-interest] Benchmark to demonstrate improvement in thread management over the years.
viktor.klang at gmail.com
Tue Aug 13 05:58:37 EDT 2013
Something I feel most people forget is fault tolerance.
If you are running code isolated in threads then how do you handle failures
in a thread? Who handles it? How do you recover from it?
On Tue, Aug 13, 2013 at 11:44 AM, Oleksandr Otenko <
oleksandr.otenko at oracle.com> wrote:
> Well, my takeaway from the slides is that the marketing of NIO is not
> necessarily the whole story, certainly not today.
> Applying your own policy for ordering and priorities is good, but this no
> longer is a "simple fork-join" / ExecuteService thread pool. On the other
> hand, if you need to implement your own execute service just to get going,
> it seems too much buck for the bang.
> Latency is usually a underestimated beast. To start with, diagnostic tools
> simply don't measure it. Then also load tests usually are not suited to
> test latency, and they hit the system with regularly spaced requests.
> On 13/08/2013 09:29, Stanimir Simeonoff wrote:
> 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
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
*Director of Engineering*
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest