On Sun, 2012-12-02 at 00:12 -0500, Sachin Nikumbh wrote: > Hi, > > Is there a way to set the SO_SNDBUF while working with the async HTTP > client? CoreConnectionPNames class does not expose this property. When I > google'ed on this topic, I found that > org.apache.commons.httpclient.params.HttpConnectionParams* *class exposes > it. > > I am comparing the throughput of the HTTP async client with Sun's > HttpURLConnection. The test case is a single threaded application that's > sending ~1Mb of data around 1000 number of times. With Wireshark, I see > that apache HTTP client's request content-length never exceeds 4096 bytes > whereas HttpURLConnectioncan have content-length of much higher size. This > is resulting in the Sun's implementation showing faster results for sending > the request. The response is received at almost the same speed as the > response content-length is same for both. > > I was wondering if tweaking SO_SNDBUF would allow me to get HTTP async > client to perform faster than Sun's. > > Any feedback would be highly appreciated. > > Thanks > Sachin
Sachin Generally NIO based HTTP transports can be expected to be as much as 25 to 50% slower that those based on the classic (blocking) I/O (as long as the number of concurrent connections is below 1000). I would say HUC being faster than HttpAsyncClient is perfectly reasonable, especially for a single threaded test case. Try that with 2000 concurrent threads and results might turn out to be totally different. I also do not think this has anything to do with the SO_SNDBUF parameter. The reason for having 4096 long TCP frames is probably your using the default request producer which in its turn serializes content entity using EntityAsyncContentProducer [1]. I would recommend using a custom request producer / response consumer implementations for optimal results. Oleg [1] http://hc.apache.org/httpcomponents-core-ga/httpcore-nio/xref/org/apache/http/nio/entity/EntityAsyncContentProducer.html#54 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
