You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by an...@thomson.com on 2007/02/21 23:13:56 UTC
Performance of stale connection check
Hi!
Are there any plans to improve performance of the stale connection
check?
Unfortunately, we can not currently migrate to HttpClient because we
can't afford 15-30 ms for stale checks in our environment where complete
HTTP requests take 10 ms. We do need the robustness provided by stale
checks so disabling them is not a good option for us.
One way to implement fast stale checks is to use non-blocking reads with
channels:
try {
channel.configureBlocking( false );
count = channel.read( buffer );
// connection closed if count == -1 (log EOF)
}
catch( Exception e ) {
// connection reset (log exception)
}
finally {
channel.configureBlocking( true );
}
This code successfully detects closed and aborted/reset connections, and
runs in < 1 ms.
Thanks.
- Andrew
Re: Performance of stale connection check
Posted by Roland Weber <ht...@dubioso.net>.
Hello Tatu,
> Also -- as to HttpClient 4.x, it looks as if baseline
> JDK requirement for blocking part is kept as 1.3.
> Since this improvement would seem like very useful
> one (assuming toggling of channel status is a fast
> operation), is there are any change this feature
> could be included as dynamically loaded plug-in?
HttpCore-main defines interfaces and a default implementation
for the connections. We can have other implementations. Stale
connection check via SocketChannel sounds like a candidate
for module-nio, which already prerequisites Java 1.4.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: Performance of stale connection check
Posted by Tatu Saloranta <co...@yahoo.com>.
--- Oleg Kalnichevski <ol...@apache.org> wrote:
...
> > This may be too late for HttpClient 3.x, but if
not,
> > would it be easy to allow pluggability of the
staleness
> > checks (I have not checked the code -- if it
...
> Hi Tatu,
>
> No, unfortunately it would not. HttpConnection in
> HttpClient 3.x is a
> concrete class and a pretty messy one on top of
> that. It is very
> difficult to customize its behavior without forking
> the whole damn
> thing.
Ok. I thought this might be the case, just wanted to
verify. I don't mind waiting for 4.0, since it seems
very promising based on discussions and progress
so far.
> Things will be radically better with HttpClient 4.0.
> Some time ago I put
> HttpCore protocol layer on top of MINA transport in
> less than half a day
> of coding. So, one can provide an alternative
> implementation of
> HttpConnection interfaces and implement some custom
> logic in place of
> the default stale connection check.
That would be good.
> > For many users,
> > Jdk 1.4. requirement would be quite acceptable,
> > and perhaps such a plug-in could be made
> accessible
> > as a separate contribution. So it would not be
part
> > of the core, but available for those who need it.
> >
>
> This is certainly an option. I experimented with
> mixed classic IO / NIO
> connection implementations a while ago at the very
> early days of
> HttpCore. I observed a noticeable performance
> degradation when using
> SocketChannel backed connections compared to those
> backed a Socket
> without an associated Channel. So, I am not sure it
> is worth paying such
> a price.
Actually, I may have misunderstood things here. My
initial
thought was that it would be possible to access the
underlying channel for a Socket, even in blocking
mode;
and to be able to do toggle handling of some
operations
(kind of enabling non-blocking mode just for staleness
checks). But looking at javadocs, I suspect I was
wrong there.
So I wasn't suggesting mandating use of NIO for other
operations at all. I know your reservations regarding
performance, and by now think NIO happens to fall into
wrong
side of 80/20 rule in many/most common use cases.
...
> > one of the things that can noticeably increase
> > latency;
> > being especially problematic with services whose
> SLA
> > is, say, 10 ms, at 99% fractile).
>
> I find this a little extreme. My recommendation was
Which part? SLAs in question, or approach?
I guess what I'm just saying is that for some use
cases
(high-speed LAN use case, where the whole
request/reply
interchange can be done in a msec or two) 20 msec
delay
is unacceptable, whereas for many others it is not.
So if there was a way to resolve this, without having
to use NIO itself, it'd be great. But I guess not.
Your points wrt. staleness checks feasibility in
general
are valid ones: I didn't realize there's lots of
scepticism towards usefulness of staleness checks
(esp.
as implements).
> always to disable
> the stale connection check and to provide a robust
> request retry handler
> instead. A production quality application must be
> prepared to deal with
> and gracefully recover from all sort of I/O failures
> _anyways_, so what
Yes... it's just that connection reuse and pooling is
well abstracted behind http components, and as such
it is hard to tell "real" problems (service going
down)
from business as usual (server closing persistent
connections to conserve resources).
And disabling the whole connection pooling (and
persistent
connections) would indeed be a bit extreme.
> is the point in treating I/O failures due to stale
> connections somehow
> differently?
I think the other reply summed it up well -- it is
question of responsibility wrt. who is to handle
which kinds of failures. Staleness check is not
visibile to the client, so it shouldn't have to
deal with it.
But refactorings done for 4.0 should allow more
modular
approach to connection pool handling, which is a
very good thing.
Once again, thank you for your thoughtly explanations,
-+ Tatu +-
____________________________________________________________________________________
8:00? 8:25? 8:40? Find a flick in no time
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
RE: Performance of stale connection check
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2007-02-22 at 15:42 -0500, andrew.adamov@thomson.com wrote:
> Oleg,
>
> > I find this a little extreme. My recommendation was always to disable
> > the stale connection check and to provide a robust request retry
> handler
> > instead. A production quality application must be prepared to deal
> with
> > and gracefully recover from all sort of I/O failures _anyways_, so
> what
> > is the point in treating I/O failures due to stale connections somehow
> > differently?
>
> I think the fundamental point is encapsulation. HTTP library users
> should not be burdened with details and complexities of internal
> connection pooling/management implementation. Unlike other I/O errors,
> stale connections are not really failures, they are expected normal
> internal events that will occur very often, so they should be handled
> automatically and transparently by HTTP library. These are the same
> reasons why TCP libraries transparently handle packet retransmission
> instead of pushing this responsibility to all clients.
>
>
Hi Andrew,
I can't disagree with that, but sometimes real life requires certain
compromises to be made. I still think there are better ways of dealing
with the problem than the stale connection check approach.
> BTW: when do you expect 1st alpha of HttpClient 4.0? :-)
> Thanks.
>
It is likely to happen around the late April to mid May time frame.
Anyways, HttpCore, the low level HTTP components suite HttpClient 4.0
will be based on, it already available and is quite usable. You may want
to take a look at HttpCore until the first alpha of HttpClient 4.0
becomes available.
Cheers
Oleg
> - Andrew
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
RE: Performance of stale connection check
Posted by an...@thomson.com.
Oleg,
> I find this a little extreme. My recommendation was always to disable
> the stale connection check and to provide a robust request retry
handler
> instead. A production quality application must be prepared to deal
with
> and gracefully recover from all sort of I/O failures _anyways_, so
what
> is the point in treating I/O failures due to stale connections somehow
> differently?
I think the fundamental point is encapsulation. HTTP library users
should not be burdened with details and complexities of internal
connection pooling/management implementation. Unlike other I/O errors,
stale connections are not really failures, they are expected normal
internal events that will occur very often, so they should be handled
automatically and transparently by HTTP library. These are the same
reasons why TCP libraries transparently handle packet retransmission
instead of pushing this responsibility to all clients.
BTW: when do you expect 1st alpha of HttpClient 4.0? :-)
Thanks.
- Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: Performance of stale connection check
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2007-02-21 at 21:07 -0800, Tatu Saloranta wrote:
> --- Oleg Kalnichevski <ol...@apache.org> wrote:
>
> > On Wed, 2007-02-21 at 17:13 -0500,
> > andrew.adamov@thomson.com wrote:
> > > Hi!
> ...
> > > This code successfully detects closed and
> > aborted/reset connections, and
> > > runs in < 1 ms.
> ...
> > Unfortunately we cannot use NIO in HttpClient 3.x
> > because of the Java
> > 1.2.2 compatibility requirement. The stale
> > connection check will always
> > remain slow due to the inherent limitations of the
> > blocking I/O in Java
> > (in many JRE implementations the effective socket
> > timeout granularity is
> > 15 - 30ms). There is not much we can do about it.
>
> This may be too late for HttpClient 3.x, but if not,
> would it be easy to allow pluggability of the
> staleness
> checks (I have not checked the code -- if it already
> is, apologies for a newbie question)?
Hi Tatu,
No, unfortunately it would not. HttpConnection in HttpClient 3.x is a
concrete class and a pretty messy one on top of that. It is very
difficult to customize its behavior without forking the whole damn
thing.
Things will be radically better with HttpClient 4.0. Some time ago I put
HttpCore protocol layer on top of MINA transport in less than half a day
of coding. So, one can provide an alternative implementation of
HttpConnection interfaces and implement some custom logic in place of
the default stale connection check.
> For many users,
> Jdk 1.4. requirement would be quite acceptable,
> and perhaps such a plug-in could be made accessible
> as a separate contribution. So it would not be part
> of the core, but available for those who need it.
>
This is certainly an option. I experimented with mixed classic IO / NIO
connection implementations a while ago at the very early days of
HttpCore. I observed a noticeable performance degradation when using
SocketChannel backed connections compared to those backed a Socket
without an associated Channel. So, I am not sure it is worth paying such
a price.
> I mention this because I know this particular issue
> is a rather important one -- for example, at my
> current (big, fortune 500) company, there is even
> recommendation is to turn off http 1.1 persistence
> altogether (when using httpclient), because of this
> additional
> latency. ;-/
> (or, rather, it's mentioned in a big http access FAQ
> as
> one of the things that can noticeably increase
> latency;
> being especially problematic with services whose SLA
> is, say, 10 ms, at 99% fractile).
>
I find this a little extreme. My recommendation was always to disable
the stale connection check and to provide a robust request retry handler
instead. A production quality application must be prepared to deal with
and gracefully recover from all sort of I/O failures _anyways_, so what
is the point in treating I/O failures due to stale connections somehow
differently?
> Also -- as to HttpClient 4.x, it looks as if baseline
> JDK requirement for blocking part is kept as 1.3.
> Since this improvement would seem like very useful
> one (assuming toggling of channel status is a fast
> operation), is there are any change this feature
> could be included as dynamically loaded plug-in?
> (if the requirement can not be increased).
> I know it is quite easy to dynamically load different
> implementations (construct an implementation factory
> as a singleton, starting with latest version; later
> on use whatever version jvm was able to load -- I used
> this to use LinkedHashMap if available, etc, for
> another project).
> I would assume pluggability is covered by 4.x design
> itself, so perhaps that's good enough.
>
Only HttpCore base module has to be Java 1.3 compatible. HttpClient 4.0
requires Java 1.4 or newer, so we could simply provide a different
HttpConnection impl for it. But as I said, it believe there are much
better ways of tackling the problem performance wise than reliance on
the stale connection check.
Cheers
Oleg
> -+ Tatu +-
>
>
>
>
> ____________________________________________________________________________________
> Don't get soaked. Take a quick peak at the forecast
> with the Yahoo! Search weather shortcut.
> http://tools.search.yahoo.com/shortcuts/#loc_weather
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: Performance of stale connection check
Posted by Tatu Saloranta <co...@yahoo.com>.
--- Oleg Kalnichevski <ol...@apache.org> wrote:
> On Wed, 2007-02-21 at 17:13 -0500,
> andrew.adamov@thomson.com wrote:
> > Hi!
...
> > This code successfully detects closed and
> aborted/reset connections, and
> > runs in < 1 ms.
...
> Unfortunately we cannot use NIO in HttpClient 3.x
> because of the Java
> 1.2.2 compatibility requirement. The stale
> connection check will always
> remain slow due to the inherent limitations of the
> blocking I/O in Java
> (in many JRE implementations the effective socket
> timeout granularity is
> 15 - 30ms). There is not much we can do about it.
This may be too late for HttpClient 3.x, but if not,
would it be easy to allow pluggability of the
staleness
checks (I have not checked the code -- if it already
is, apologies for a newbie question)? For many users,
Jdk 1.4. requirement would be quite acceptable,
and perhaps such a plug-in could be made accessible
as a separate contribution. So it would not be part
of the core, but available for those who need it.
I mention this because I know this particular issue
is a rather important one -- for example, at my
current (big, fortune 500) company, there is even
recommendation is to turn off http 1.1 persistence
altogether (when using httpclient), because of this
additional
latency. ;-/
(or, rather, it's mentioned in a big http access FAQ
as
one of the things that can noticeably increase
latency;
being especially problematic with services whose SLA
is, say, 10 ms, at 99% fractile).
Also -- as to HttpClient 4.x, it looks as if baseline
JDK requirement for blocking part is kept as 1.3.
Since this improvement would seem like very useful
one (assuming toggling of channel status is a fast
operation), is there are any change this feature
could be included as dynamically loaded plug-in?
(if the requirement can not be increased).
I know it is quite easy to dynamically load different
implementations (construct an implementation factory
as a singleton, starting with latest version; later
on use whatever version jvm was able to load -- I used
this to use LinkedHashMap if available, etc, for
another project).
I would assume pluggability is covered by 4.x design
itself, so perhaps that's good enough.
-+ Tatu +-
____________________________________________________________________________________
Don't get soaked. Take a quick peak at the forecast
with the Yahoo! Search weather shortcut.
http://tools.search.yahoo.com/shortcuts/#loc_weather
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: Performance of stale connection check
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Wed, 2007-02-21 at 17:13 -0500, andrew.adamov@thomson.com wrote:
> Hi!
>
> Are there any plans to improve performance of the stale connection
> check?
>
> Unfortunately, we can not currently migrate to HttpClient because we
> can't afford 15-30 ms for stale checks in our environment where complete
> HTTP requests take 10 ms. We do need the robustness provided by stale
> checks so disabling them is not a good option for us.
>
> One way to implement fast stale checks is to use non-blocking reads with
> channels:
>
> try {
> channel.configureBlocking( false );
> count = channel.read( buffer );
> // connection closed if count == -1 (log EOF)
> }
> catch( Exception e ) {
> // connection reset (log exception)
> }
> finally {
> channel.configureBlocking( true );
> }
>
> This code successfully detects closed and aborted/reset connections, and
> runs in < 1 ms.
>
> Thanks.
>
> - Andrew
>
Andrew,
Unfortunately we cannot use NIO in HttpClient 3.x because of the Java
1.2.2 compatibility requirement. The stale connection check will always
remain slow due to the inherent limitations of the blocking I/O in Java
(in many JRE implementations the effective socket timeout granularity is
15 - 30ms). There is not much we can do about it.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org