hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: Performance Issue
Date Tue, 29 Jul 2003 03:44:34 GMT
Just sending a quick note before I go to bed.  I did some testing with 
the example code and am now quite confident that HTCM is doing what it 
should.  I have not had time to add any DEBUG code but hopefully I will 
get to it tomorrow.

Todd, one thing I noticed is that you are setting maxConnectionsPerHost 
to the number of threads you are creating.  This pretty much defeats 
the purpose of using the MTCM and there is no need to share 
connections.  There are enough connections for each thread to just own 
one.  This is not really related to the problem with isStale() but I 
thought I would mention it.

Oleg, have you done any timings with Todd's example code?  I have found 
that disabling isStale() is this case seems to have little effect on 
execution time.  I was not able to test against 2.0 alpha3 and am 
wondering if it would make any difference.


On Monday, July 28, 2003, at 11:45 AM, 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

View raw message