4 ms·
The article is from back in 2008 so I'd firstly dispute its accuracy with modern JVMs. It's not just speed (The speed obviously changes as you change number of
by speckledjim 15y ago
The article is from back in 2008 so I'd firstly dispute its accuracy with modern JVMs.
It's not just speed (The speed obviously changes as you change number of connections - 100k threads isn't going to beat 100k NIO connections). It's also that it's more scalable, better code, more maintainable, less prone to bugs, and you don't have to worry as much about concurrency issues. I'd argue that the lines of code is likely to be less also. And memory usage is likely to be less.
- spullara 15y agoAnd performance suffers terribly when you don't need to scale the number of connections. Like anything, use it when it is needed.
- gojomo 15y agoFor better or worse, JVMs don't change that fast. (In 2008, the latest official release was JDK6, reaching 'update 12' in December. In July 2011, until the official release of JDK7 next week, the latest official JVM is still JDK6, 'update 26'.) Or do you know of specific NIO performance improvements between JDK6 in 2008 and JDK6u26, or in JDK7? 100k threads isn't going to beat 100k NIO connections That may be true but I wouldn't assume it with certainty without evidence. Threading has been improving, too. Tyma's 2008 presentation mentioned a JVM limit at the time of 16000 threads, but that may have changed as well. A single-threaded NIO implementation, using only one core, could very plausibly lose to a 100K-threaded implementation on a multicore machine. And once you split your NIO over a few threads to use cores effectively, you have most of the same concurrency worries as with connection-per-thread approaches.