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]
