[concurrency-interest] Benchmark to demonstrate improvement in thread management over the years.

√iktor Ҡlang 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?

Cheers,
√


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.
>
>
> Alex
>
>
> 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.
>
>
> Stanimir
>
>
> On Mon, Aug 12, 2013 at 5:06 PM, Oleksandr Otenko <
> oleksandr.otenko at oracle.com> wrote:
>
>>  http://www.slideshare.net/e456/tyma-paulmultithreaded1
>>
>> Alex
>>
>>
>> On 12/08/2013 14:03, Unmesh Joshi wrote:
>>
>>  Hi,
>>
>>  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
>> threads.
>> 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?
>>
>>  Thanks,
>> Unmesh
>>
>>
>>   _______________________________________________
>> 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
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


-- 
*Viktor Klang*
*Director of Engineering*
Typesafe <http://www.typesafe.com/>

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130813/a1da3e47/attachment-0001.html>


More information about the Concurrency-interest mailing list