Mike, I have run the test with 3 different HttpClient versions and the results I have got are troubling
2.0a3: 50 requests in 0.390 min 2.0b2: 50 requests in 0.423 min 2.0rc1 (with 'stale' connection check removed): 50 requests in 0.440 min I'll be digging further Oleg PS: I have been using Tomcat 4.1.24 instead of Jetty to host the test web application -----Original Message----- From: Michael Becke [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 29, 2003 5:45 AM To: Commons HttpClient Project Subject: Re: Performance Issue 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. Mike 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" <[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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
