On 7/29/10 11:18 AM, Oleksiy Stashok wrote:
> Yeah, I read similar articles before.
>
>> A bit dated, but still interesting read even though my experiments
>> don't support these claims:
>> http://www.thebuzzmedia.com/java-io-faster-than-nio-old-is-new-again/
>>
>> The biggest omission I found was that the claims are based on the
>> assumption that the clients are really fast. But as we know, in
>> reality this is usually not the case.
> IMO it doesn't depend much on how fast clients are, may be indirectly.
> As I understood the main point was that modern OSes have very
> optimized thread and memory management. So big amount of idle threads,
> which have some context associated and wait for blocking I/O
> operations to complete, have minimal impact on the active threads. And
> idle<->active thread state switch (with all its context) is not so
> expensive operation.
One important think to remember is that the number of threads a JVM can
handle is 16 000. When using a NIO based application, you may exceed
this number when dealing with hundred of thousands sessions. Either
Grizzly, MINA or Netty3 have already faced such constraints, and I don't
see how possibly you can use a plain IO solution in this case.
> For me It could be interesting to see the benchmark comparison for
> some real-life scenario, let's say web/app server.
What would be *very* interesting is to see how a plain IO server behaves
when reaching the limit (ie with 16 000 connected clients), compared to
a NIO based app. That includes the memory consumption, not only the CPU.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com