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

Oleksandr Otenko oleksandr.otenko at oracle.com
Tue Aug 13 05:44:22 EDT 2013


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 <mailto: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 list
>>     Concurrency-interest at cs.oswego.edu  <mailto:Concurrency-interest at cs.oswego.edu>
>>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu
>     <mailto:Concurrency-interest at cs.oswego.edu>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130813/353b1af5/attachment.html>


More information about the Concurrency-interest mailing list