On 7/29/10 3:14 PM, charlie hunt wrote:
> Emmanuel Lécharny wrote:
>> 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.
> Just a small clarification ... the number of threads a modern JVM can
> support is not necessarily limited to 16,000 threads. It's more a
> function of the address space consumed by a Java thread and the amount
> of addressable space available to the JVM process along with the
> address space consumed by other artifacts of the JVM.
You are plain right. The 16K number is just extracted from the slides
(slide 25, more specifically).
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com