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 Issue
Date Mon, 28 Jul 2003 17:11:02 GMT
Todd, 
I believe we have identified the reason for performance degradation
which is a stale connection check introduced in beta-1, not the
multi-threaded connection manager itself. The bogus log entries about
connection being created are caused by the connection wrapper class,
which is indeed created every time a connection is obtained from the
connection pool. This said, you may still send your test application but
I believe we can trust Mike on his word that multi-threaded connection
manager is not the problem

Cheers

Oleg



On Mon, 2003-07-28 at 17:45, Todd Wolff wrote:
> Glad I could contribute.  I've put together a test harness that reproduces
> the connection issue.  Unless I'm missing something, I'm pretty sure only a
> single instance of MTCM is being accessed by the sending threads.  Should I
> send it to you and Mike directly rather than taking up bandwidth on the list
> (it's 250k.)
> 
> 
> 
> Todd
> 
> 
> ----- Original Message -----
> From: "Oleg Kalnichevski" <olegk@apache.org>
> To: "Commons HttpClient Project" <commons-httpclient-dev@jakarta.apache.org>
> Sent: Sunday, July 27, 2003 7:10 AM
> Subject: Re: Performance Issue
> 
> 
> > Todd,
> >
> > I think I have identified the problem or one of the problem that
> > contributed to the noticeable performance degradation  for short HTTP
> > messages in post 2.0a3 releases. So, many thanks for bringing up this
> > issue
> >
> > Further, see my comments below
> >
> > On Sun, 2003-07-27 at 03:36, Todd Wolff wrote
> >
> >
> > > Also, although unrelated to the relative decrease in
> > > performance, I did notice that in both tests a new connection is created
> per
> > > request.
> >
> > Usually HttpClient does a pretty good job reusing connections. You can
> > see the evidence of that from the log that you have produced:
> >
> > ...
> > [DEBUG] HttpMethodBase - -Resorting to protocol version default close
> > connection policy
> > [DEBUG] HttpMethodBase - -Should NOT close connection, using HTTP/1.1
> > [DEBUG] MultiThreadedHttpConnectionManager - -Freeing connection:
> > ...
> >
> > What is fishy here is why the connection manager keeps on creating new
> > connections instead of reusing those active ones that have been just
> > returned to the pool. I can't tell. My guess is that you end up creating
> > an instance of MultiThreadedHttpConnectionManager per thread in your
> > application that completely defeats its purpose. You should be sharing
> > the same instance of mtcm between all your worker threads in order to
> > make connection pooling effective. This is just a guess, though. You'll
> > have to wait until Michael Becke gets on-line. He's the one who wrote
> > MultiThreadedHttpConnectionManager in the first place, so he will be of
> > MUCH more help here.
> >
> > Mike, we clearly need more DEBUG logs in the
> > MultiThreadedHttpConnectionManager. At the moment it is difficult to
> > tell what is going on there.
> >
> > Cheers
> >
> > Oleg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
> 


Mime
View raw message