commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "allen huang" <coolallenhu...@gmail.com>
Subject Re: [httpclient_common]_why httpclient's speed is the same with JDK httpurlconnection
Date Wed, 07 Feb 2007 10:58:51 GMT
Hi Craig,
I use JDK5.0. Actually, Some guys told me that HttpClient is very fast. Then
I perform this testing to find how more it runs than JDK httpurlconnection.
And, of course, the test result could not feed my need, in another words, I
think this speed(200ms to download a normal page about tens of kbytes)is too
flow. And, I wonder if my using to httpclient is perfect, I just follow the
apache guide to do that.

On 2/7/07, Craig McClanahan <craigmcc@apache.org> wrote:
>
> On 2/6/07, allen huang <coolallenhuang@gmail.com> wrote:
> >
> > Hi,
> > I have a problem when trying to comparing the speed between JDK
> > HttpURLConnection and HttpClient.
> >
> > Now I have two methods, one is performed with jdk(1.5)
> httpurlConnection,
> > the other is performed with httpClient( 3.0.1). Both of them try to
> > download
> > the same webpage(http://jakarta.apache.org).After<
> > http://jakarta.apache.org%29.After>testing,
> > the average time which performed JDK httpurlconnection  is  200ms,
> > so as the one which performed httpclient.That means their speeds are
> > almost
> > the same.
> >
> > So, since HttpClient use persistence connection default but JDK do not,
> > why
> > httpClient's speed could not be more fast than JDK?
>
>
> What JDK are you using?  IIRC, the JDK's HttpUrlConnection class has
> defaulted to persistent HTTP connections since at least JDK 1.1 days.



Another problem is, is it normal to httpclient to use 200ms to download a
> > page like http://jakarta.apache.org? I mean, when using persistence
> > connection, maybe this could not be accepted.
>
>
> The timing of something like this, especially on a relatively small page,
> is
> going to be so dominated by the speed of your connection to the Internet
> that "acceptable" is in the eyes of the beholder.  Is it fast enough for
> your requirements?  If so, it doesn't matter which technology you choose
> --
> they both work.  Is it too slow?  Then it doesn't matter which technology
> you choose -- they both fail to meet your needs.  Is your average need to
> download multiple megabytes instead of a couple hundred kbytes?  Then the
> test you ran is totally meaningless because it did not reflect your real
> requirements.
>
> Any help will be great appreciated
>
>
> Craig
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message