On Thu, Apr 02, 2009 at 10:42:38AM +0200, Gruntz,Dominik wrote:
> Thanks for your help!
> I tried to simplify my question and therefore omitted some details. Actually, 
> the resource I am accessing has a body of length 0. It is generated by a 
> Servlet.service method which does not return any data and simply sets the 
> content length to zero.
> 
>    protected void service(HttpServletRequest req, HttpServletResponse res) { 
>       System.out.println("request from 
> "+req.getRemoteHost()+":"+req.getRemotePort());        
>       res.setContentLength(0);
>    }
> 
> Obviously, I measured the timings without the println statement. But with 
> that statement enabled I see, that both HttpClient and HttpURLConnection 
> reuse the same socket for their requests, thus they both have to read the 
> whole content (although in my case this content has size 0) and they both 
> reuse the connection (the method name connect on HttpURLConnection is 
> misleading).
> 
> So still the question: why these timing differences? 
> 

HttpClient (at least version 4.0) is known to be faster or as fast as
HttpURLConnection. Development of HttpClient 3.x effectively ceased
several years ago. 

Look for flaws in your benchmark, like accidentally leaving logging on.

Oleg



> Thanks for any further advice.
> 
> Best wishes
> Dominik
> 
> 
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:[email protected]] 
> Sent: Donnerstag, 2. April 2009 09:50
> To: HttpClient User Discussion
> Subject: Re: HttpClient performance
> 
> On Thu, Apr 02, 2009 at 01:54:56AM +0200, Gruntz,Dominik wrote:
> > Hi,
> > I wrote a method which requests a resource several times from on a servlet 
> > server (on localhost). 
> > It seems to me that the version using HttpClient is abouot a factor of 
> > 20-30 slower than the 
> > version based on Sun's HttpURLConnection. I cannot believe these figures 
> > and ask you, where 
> > I misused the HttpClient class. If the result is correct, what is the 
> > reasen that HttpClient
> > is slower?
> > 
> > The HttpClient method looks as follows:
> > 
> >     static void doJakartaCommons(String path) throws Exception {
> >             HttpClient client = new HttpClient();
> >             for (int i = 0; i < 1000; i++) {
> >                     HttpMethod method = new GetMethod(path);
> >                     client.executeMethod(method);
> >                     int code = method.getStatusCode();
> >                     if(code != 200)
> >                             throw new IllegalStateException();
> >                     method.releaseConnection();
> >             }
> >     }
> > 
> > 
> > The version bsaed on HttpURLConnection looks as follows:
> > 
> >     static void doHttpConnection(String path) throws Exception {
> >             for (int i = 0; i < 1000; i++) {
> >                     URL url = new URL(path);
> >                     HttpURLConnection c = (HttpURLConnection) 
> > url.openConnection();
> >                     c.connect();
> >                     int code = c.getResponseCode();
> >                     if(code != 200)
> >                             throw new IllegalStateException();
> >             }
> >     }
> > 
> > 
> > Thanks for your help.
> > Dominik
> > 
> > 
> 
> Your performance benchmark is completely flawed. You are comparing
> apples to oranges. Here's what HttpURLConnection test does: open a
> connection, execute request, read response head, drop connection. Here's
> what your HttpClient test case does: open a connection, execute request,
> read response head, read response body (!!!!), re-use connection.
> Obviously opening a new local connection is significantly faster than
> reading a larger response body
> 
> Performance benchmarking is a tricky business.
> 
> 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]

Reply via email to