hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wolfgang Hoschek - DSD Staff <whosc...@lbl.gov>
Subject RE: Performance HTTPClient vs. ab
Date Thu, 14 Aug 2003 23:38:03 GMT
Oleg,

Thanks for the kind help with working, well-performing code, which 
resolves the problem according to bench runs here.

Just for the record, so that others may benefit as well,
bench runs for *this* use case show the following:

- GetMethod vs. PostMethod makes no noticeable difference
- SimpleHttpConnectionManager vs. MultiThreadedHttpConnectionManager 
makes no noticeable difference
- disabling stale connections with 
connectionMgr.setConnectionStaleCheckingEnabled(false)
improves performance by a factor of 50 (note: factor, not percent).

With this in place, performance is perfectly reasonable, indeed.
Perhaps this side effect of disabling stale connections should be 
reflected in the javadoc or tutorials.
Congrats to HTTPClient.

Wolfgang.

> Wolfgang,
> 
> Please allow me to point out that your comparison is not completely accurate. Apache
\
> benchmark (I assume) uses HTTP GET requests, whereas your test application uses HTTP
\
> POST requests. Besides, you should have used HttpCliet's simple (non-multithreaded) \
> connection manager to be on an equal footing with AB. I have tweaked your application
\
> somewhat (See the source code attached below) and that is what I got
> 
> 1000 HTTP GET requests against local Tomcat 4.1.27 running on RedHat 9, Sun JRE 1.4.2
> 
> HttpClient (Sun JRE 1.4.2): 3.209 [sec] vs Apache Benchmark: 0.910710 [sec]
> 
> I personally find these results reasonable, taking into account that AP (most likely)
\
> does not provide any sort of an object model unlike HttpClient.
> 
> Bottom line, the trick there was to disable stale connections check which is terribly
\
> taxing in terms of performance for massive amount of very short requests.
> 
> Cheers
> 
> Oleg
> 


Mime
View raw message