hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Performance of stale connection check
Date Thu, 22 Feb 2007 10:58:46 GMT
On Wed, 2007-02-21 at 21:07 -0800, Tatu Saloranta wrote:
> --- Oleg Kalnichevski <olegk@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


Mime
View raw message