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

Stanimir Simeonoff stanimir at riflexo.com
Tue Aug 13 06:20:59 EDT 2013


Latency is important when you have systems that most of the work is in the
form of subscribe and receive-a-lot (trading quotes and the like), in such
cases one would like all the clients to receive the information w/ similar
latencies, instead someone getting bursts.
Still writing the framework is like couple thousand lines of code (probably
w/ some optimistic lock free here and there). If you have mainly
request->response workload, the good old thread pool is just fine unless a
malicious attacker decides to DoS. You don't need DDoS w/ java
socket.getOutputStream().write() implementation. For instance, it's trivial
to starve the BIO thread pool of tomcat w/ a single machine.

Stanimir


On Tue, Aug 13, 2013 at 12:44 PM, 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130813/1fc9270a/attachment.html>


More information about the Concurrency-interest mailing list