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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
