hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Berlin <sber...@gmail.com>
Subject Re: [HttpCommon] The trouble with NIO is not about performance
Date Sat, 20 Aug 2005 14:09:58 GMT
It is possible to use timeouts when using NIO, however you have to add
the behaviour in (and the timing will never be exact).  Essentially,
you just need to maintain a secondary object per selection-attachment
that keeps track of the timeout required for that operation, and do
short timed-out selects.  If the current time after the select
finishes exceeds the time allotted for an event, that SelectionKey is
cancelled and the associated channels are closed.  This is much easier
to do with connects, because it's a one-time behaviour -- but it is
possible to do with reads (and with writes it's also possible, even
though there never was a parameter for timing out on writes with
blocking streams).

Thanks,
 Sam

On 8/20/05, Oleg Kalnichevski <olegk@apache.org> wrote:
> On Fri, 2005-08-19 at 22:10 -0400, Michael Becke wrote:
> > Is using selectors the only way to support read timeout?
> 
> The only one I know of and I have been working with NIO for quite some
> time
> 
> > We certainly
> > could choose which factory to use based up SO_TIMEOUT, but it seems
> > like a bit of a hack.  There must be a better way.  Would it be
> > possible to use blocking NIO and the old method for handling
> > SO_TIMEOUT and still see some of the performance benefits of NIO?
> >
> 
> Not that I know of. This is what the javadocs say:
> "...Enable/disable SO_TIMEOUT with the specified timeout, in
> milliseconds. With this option set to a non-zero timeout, a read() call
> on the InputStream associated with this Socket will block for only this
> amount of time..."
> 
> SO_TIMEOUT will have effect on
> channel.socket().getInputStream().read(stuff);
> 
> SO_TIMEOUT will have NO effect on
> channel.read(stuff);
> 
> There are enough people who have been complaining loudly about it,
> because this pretty much renders blocking NIO useless.
> 
> Oleg
> 
> > Mike
> >
> > On 8/19/05, Oleg Kalnichevski <olegk@apache.org> wrote:
> > > Folks,
> > >
> > > I think we (and especially I) have been looking at the problem from a
> > > wrong angle. Fundamentally the blocking NIO _IS_ faster than old IO (see
> > > the numbers below). This is especially the case for small requests /
> > > responses where the message content is only a coupe of times larger than
> > > the message head. NIO _DOES_ help significantly speed up parsing HTTP
> > > message headers
> > >
> > > tests.performance.PerformanceTest 8080 200 OldIO
> > > ================================================
> > > Request: GET /tomcat-docs/changelog.html HTTP/1.1
> > > Average (nanosec): 10,109,390
> > > Request: GET /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> > > Average (nanosec): 4,262,260
> > > Request: POST /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> > > Average (nanosec): 7,813,805
> > >
> > > tests.performance.PerformanceTest 8080 200 NIO
> > > ================================================
> > > Request: GET /tomcat-docs/changelog.html HTTP/1.1
> > > Average (nanosec): 8,681,050
> > > Request: GET /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> > > Average (nanosec): 1,993,590
> > > Request: POST /servlets-examples/servlet/RequestInfoExample HTTP/1.1
> > > Average (nanosec): 6,062,200
> > >
> > > The performance of the NIO starts degrading dramatically only when
> > > socket channels is unblocked and is registered with a selector. The sole
> > > reason we need to use selectors is to implement read socket timeout. To
> > > make matters worse we are forced to use one selector per channel only to
> > > simulate blocking I/O. This is extremely wasteful. NIO is not meant to
> > > be used this way.
> > >
> > > Fundamentally the whole issue is about troubles timing out idle NIO
> > > connections, not about NIO performance. What if we just decided to NOT
> > > support socket timeouts on NIO connections? Consider this. On the client
> > > side we could easily work the problem around by choosing the type of the
> > > connection depending upon the value of the SO_TIMEOUT parameter.
> > > Besides, there are enough client side applications where socket read
> > > timeout is less important total the request time, which require a
> > > monitor thread anyway. This kind of applications could benefit greatly
> > > from NIO connections without losing a bit of functionality. The server
> > > side is by far more problematic because on the server side socket read
> > > timeout is a convenient way to manage idle connections. However, an
> > > extra thread to monitor and drop idle connections may well be worth the
> > > extra performance of NIO.
> > >
> > > What do you think?
> > >
> > > Oleg
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


Mime
View raw message