On Fri, 2004-08-20 at 21:23, Zulfi Umrani wrote:
> >>(3) HttpClient handsomely beats HttpURLConnection when streaming out
> entity enclosing requests (POST, PUT)<<
> 
> Hi Oleg,
> I am a bit skeptical about your test#3 for POST. I am doing POST myself
> but the performance of HttpClient is not better than
> java.net.HttpURLConnection. I have posted another email for that on the
> list. Can you please double check that or provide some information about
> what did you exactly do for that test.

Zulfi,

I attached the full source code of the tests. Please once again see the
link

http://marc.theaimsgroup.com/?l=httpclient-commons-dev&m=109300858528261&w=2

Feel free to do more research in that area and post us on the results. I
just know for a fact that due to the design limitations
HttpURLConnection always buffers the request body, so HttpClient is
bound to be faster (especially when executing POST requests in multiple
threads) for any but the tiniest requests when configured to stream out
the request body.

Oleg

> 
> Thanks,
> Zulfi
> 
> >>> [EMAIL PROTECTED] 8/20/2004 11:54:52 AM >>>
> > I do not remember which earlier releases I used. I only remeber that
> it
> > did not have the rcX attached to it. I am not sure if it matters now.
> I
> > guess, the only thing we are concerned here is whether we can get
> > HttpClient performance better than JDK or not. If yes, then how do
> we
> > get it? I guess some other folks had a similar problem before.
> Wondering
> > if a solution to the problem was found or not? 
> > 
> 
> Zulfi,
> 
> You can see the full results that I got at the following location:
> 
> http://marc.theaimsgroup.com/?l=httpclient-commons-dev&m=109300858528261&w=2
> 
> 
> The short summary
> 
> (1) What I see is that HttpURLConnection tends to perform better by a
> constant delta of 1-3ms for those methods that produce smaller (below
> 5kb) response entities. 
> 
> (2) For methods producing larger response entities (over 50kb)
> HttpClient tends to perform better
> 
> (3) HttpClient handsomely beats HttpURLConnection when streaming out
> entity enclosing requests (POST, PUT)
> 
> (4) HttpClient 2.0.1 with the stale connection check disabled performs
> better than HttpClient 2.0-alpha3.
> 
> Hope this clarifies the situation
> 
> Oleg
> 
> 
> > Hope this helps you in understanding the problem. 
> > 
> > -Zulfi
> > 
> > 
> > 
> > -----Original Message-----
> > Subject: HttpClient performance
> > Date: Fri, 20 Aug 2004 08:39:21 +0100
> > From: Kalnichevski, Oleg <[EMAIL PROTECTED]>
> > 
> > 
> > Zulfi,
> > 
> > If you expect us to react on this report, you have to be a little
> more
> > specific on how exactly you measured the performance, exactly what
> kind
> > of HTTP methods your tests included, exactly what
> pre-release-candidate
> > you are referring to, and what exactly you mean by "but it is still
> > slower than using JDK-1.4.2". Do you actually mean using
> > HttpURLConnection? Raw socket? Something else?
> > 
> > I'll run a few tests of my own to see if I get significant
> difference
> > in terms of performance between HttpClient 2.0alpha3, 2.0.1, CVS
> HEAD
> > (post-3.0a1) and HttpURLConnection
> > 
> > Oleg
> > 
> > 
> > -----Original Message-----
> > From: Zulfi Umrani [mailto:[EMAIL PROTECTED] 
> > Sent: Friday, August 20, 2004 7:06 AM
> > To: [EMAIL PROTECTED] 
> > Subject: HttpClient performance
> > 
> > 
> > Hi,
> > 
> > Just wanted to get the latest information on the performance issues
> > reported earlier. I have gone through the below emails from Archive,
> > but
> > could not get a definite solution to the performance problem.
> > Wondering
> > whether a definite solution was found and whether there is a patch
> > available. We tested the performance using pre-release-candidate
> > version
> > of HttpClient(2.0) and it was much better than the release-candidate
> > versions and the final 2.0 version of HttpClient. Please note that I
> > did
> > try using the  SimpleHttpConnectionManager and calling the
> > setConnectionStaleCheckingEnabled method with false argument. The
> > performance does improve, but it is still slower than using
> JDK-1.4.2.
> > I
> > will appreciate if someone who knows the solution can respond.
> >    
> > 
> >
> http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=781750
> 
> > 
> >
> http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=781859
> 
> > 
> >
> http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=781909
> 
> > 
> >
> http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=779703
> 
> > 
> > 
> > Thanks.
> > 
> > 
> > 
> > 
> > 
> >
> ---------------------------------------------------------------------
> > 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]

Reply via email to