Yeah - what I said! ;) Hi Brian. We've got to stop chatting like this. haha
Rob ----- Original Message ---- From: Brian McCallister <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, February 22, 2008 8:13:19 PM Subject: Re: NIO vs NPTL+standard IO Er, What Rob said. Hey, hi Rob! -Brian On Fri, Feb 22, 2008 at 5:12 PM, Brian McCallister <[EMAIL PROTECTED]> wrote: > You *will* almost always see better performance for blocking IO with a low > number (1700 in his test) of connections/threads. > > NBIO is more interesting when you want a lot of connections. > > -Brian > > > On Wed, Feb 20, 2008 at 11:03 AM, Rob Butler <[EMAIL PROTECTED]> wrote: > > > I suspect this comes down to using the right tool (or API) for the job. > > > > * Latency will be lower with normal IO because only a single thread is > > involved with no hand-off between the IO thread and the 'worker' thread. > > > > * In general throughput will be higher with normal IO as long as the > > number of connections/threads is reasonable. Probably a few hundred > > simultaneous connections/threads on most OS's, more on Linux with NPTL. You > > can probably get to 4-5K connections/threads on NPTL safely, but now your > > limited to only running on Linux with NPTL. If you want that many > > simultaneous connections on other OS's, you should use NIO. > > > > * If your needs are lots of simultaneous connections (10K or more), that > > aren't very IO heavy, NIO is the way to go - even on NPTL. > > > > You can't even say that an HTTP server should use normal IO, or should > > use NIO - because it depends on how the HTTP server is going to be used. If > > your going to have lots of clients doing ajax stuff or using continuations, > > go with NIO. If not, use normal IO. > > > > Rob > > > > ----- Original Message ---- > > From: Mike Heath <[EMAIL PROTECTED]> > > To: [email protected] > > Sent: Wednesday, February 20, 2008 1:23:48 PM > > Subject: Re: NIO vs NPTL+standard IO > > > > I've > > suspected > > for > > a > > while > > that > > you > > can > > getter > > better > > performance > > using > > thread-per-connection > > on > > Java. > > I've > > never > > actually > > tested > > this > > theory > > though. > > There > > are > > certainly > > a > > lot > > of > > scenarios > > where > > you > > can > > get > > lower > > latency > > using > > thread-per-connection > > because > > you > > don't > > have > > the > > overhead > > of > > queuing. > > > > Perhaps > > we > > should > > start > > looking > > seriously > > at > > implementing > > thread-per-connection > > IoServices > > for > > MINA > > so > > we > > can > > do > > some > > apples > > to > > apples > > performance > > comparisons > > between > > NIO, > > IO, > > and > > APR. > > > > -Mike > > > > Stefano > > Bagnara > > wrote: > > > > > Today > > I > > found > > another > > blog > > post > > on > > the > > "usual" > > topic: > > > > > > > http://mailinator.blogspot.com/2008/02/kill-myth-please-nio-is-not-faster-than.html > > > > > > > > > > > Is > > this > > FUD > > or > > a > > new > > trend > > that > > MINA > > should > > take > > care > > of? > > > > > > > > Is > > there > > any > > plan > > to > > support > > standard > > IO > > as > > a > > transport > > for > > MINA > > based > > > > > applications? > > > > > > > > It > > would > > be > > useful > > to > > understand > > how > > a > > MINA > > based > > application > > could > > > > > "switch > > back" > > to > > multithreaded > > standard > > IO > > and > > result > > in > > better > > > > > throughput > > on > > modern > > JVM/OS. > > > > > > > > Thank > > you, > > > > > Stefano > > > > > > > > > > > > > > > > > > > > > > ____________________________________________________________________________________ > > Be a better friend, newshound, and > > know-it-all with Yahoo! Mobile. Try it now. > > http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ > > > > > ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
