I saw this show up on dzone:
and I’m wondering what you guys think. Esp considering resolve whitnessed here that io doesn’t cut it and nio is the way to go.
I don’t see any place where either of these guys directly mentions it, but it seems as though the discussion is really:
- NIO in a single-threaded environment
[li][IO in a multi-threaded environment/li]
There are obvious reasons why IO is going to out-perform in these circumstances. Not because IO is faster, but because you’ve got multiple threads handling. No, NIO doesn’t technically block, but CPU IS taken up when processing occurs. I say, put your hands together and get a multi-threaded NIO solution and I think the debate will end. 
I have done testing on IO versus NIO and my results were not quite the same. I’ve seen drastic performance increases on lots of connections by using NIO properly. I will state though, that this was done on JGN, which actually allows you to run several threads with NIO, so I was getting the best of both worlds.
I agree with Matt,
NIO with lots of threads would behave in a similar way. Apache MINA uses NIO as well as thread pools, so it’s capable of taking advantage of the apparently better thread-handling in Linux.
I’m not certain of this, but when NIO came out, wasn’t old IO refactored to use NIO under the bonnet, so they’re really both the same except for how old IO restricts you to one thread per connection?
The typical NIO setup they take there is 1 select thread and adding x reactors so it is making use of multi-core. eg simply saying wel the io bit here takes advantage of the 2…x core doesn’t fly.
See the reactor pattern
http://www.cs.wustl.edu/~schmidt/patterns-ace.html
http://www.scribd.com/doc/267947/Scalable-IO-in-Java-make-it-nonblocking
I’m guessing using the posix lib thread-overhead is a lot less significant in the numbers of thread they use. and in the traditional io approach, that what a thread executes is similair thread life is shorter perhaps leaving it all open for better optimalisations aspossed to NIO way. ie the bottleneck has shifter from threads to something else, and this something else is beter optimised by the jvm for io then nio. But this is all totally unfounded at this time.
I’m hopign to hear a response from adam as it is much more his field then mine.
Sorry to not be more informative, but all I can say is:
-
As JVM has grown, a lot of areas have never really been fixed by Sun, I/O being one of the major ones. Java 1.4.2 had/has some horrendous performance problems - c.f. my posts from a few years that showed that you could beat Sun’s implementation of scatter/gather buffer read/writes by mulitple orders of magnitude by re-implementing the same algorithm yourself in something like 5 lines of code. I.e. whatever they’d shipped sucks so bad it’s worse than the “naive” implementation a normal coder would come up with purely in java, with no access to OS structures, libraries, etc.
-
java 1.4.x was the first to get native memory. Even ignoring the bugfixing that’s taken place, my experience is that performance has improved all over the place considerably with anything that touches the buffers part of NIO in the 4 years or so since 1.4.2 launched. I would be very suspicious of anything not done on a “current, latest” JVM. What’s the point testing on a new-ish linux kernel but using an out-of-date JVM?
-
in commercial projects, I switched over to using java 5.x as standard deployment for live servers almost 3 years ago (IIRC mainly because of bugfixes that hadn’t been backported to 1.4.x). I think it’s safe to say that even for commercial work you should be only looking at 6.x and above by now.
Life is busy, too busy for me to spend much time looking at this stuff right now :(.
im not an expert in this field but i can restate what ive been told when wondering the same things on IRC channels.
NIO is much more memory processor friendly, it is capable of the 10000 + connections that some saw as a magical limit for the longest time. It is however not as good when it comes to pure performance, im not sure by how much it underperforms regular threaded IO but it was the position of several of the reputable members of the #java channel on freenode that it did.
NIO is the right way to go if you need massive ammounts of connections and it dosent matter that much if its not lightning speed.
IO is faster, it does this at the cost of alot more memory, it uses one thread per connection, imagine that for 10000 users. Also IO does not ‘block’ any other connections, one thread receives a message and in multicore machines so can any of the other threads that are waiting on data.
Basically it comes down to NIO being slower but more efficient, IO being faster but more intense on the machine.
I’m not sure if these ‘facts’ are correct but it is what i was told by people whom usually seems to know what they are talking about.
I, because of these reason have stuck with using IO, that and NIO seems oddly annoying to implement.
//VoS
NIO’s API is a lot closer to how you should be implementing your networking code. So, yes, it takes a while to get a fully working NIO-based server running (lots of code to write), but it’s a cleaner usage of networking once you’ve done it. IMHO.
Which is why I wrote the simplest NIO server I could and then stuck the source code up here - once you have the basic server working correctly, it’s easy to use.
[quote=“blahblahblahh,post:7,topic:31396”]
So why isn’t that code in the standard API?
See blahblahblahh’s thread about it here:
http://www.java-gaming.org/index.php/topic,18077.0.html
It ‘only’ does String based I/O, and implements its own protocol to merge split messages back together (2 bytes length header).
Those two things made me deside it would not cut it for me (sorry) and I guess it would not be suitable for the ‘standard API’. That’s why I finished my own NIO wrapper a few days ago, which does not modify any bytes you send/receive. You have to merge/split your TCP packets yourself, or you can use the utility class (ByteQueue) to do it for you.
It would be great to have some wrapper around NIO in the standard API, but to be honest, I think everybody that needs NIO knows how to handle it, and everybody else can do just fine with plain old java.io and java.net (with a few dozen connections).
Fair enough. =)