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]
