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" <[EMAIL PROTECTED]> > To: "Commons HttpClient Project" <[EMAIL PROTECTED]> > 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: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]