cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Async http client experiments....
Date Fri, 27 Jul 2012 20:25:41 GMT
On Friday, July 27, 2012 03:11:18 PM Jeff Genender wrote:
> Any reason you chose not to use Mina?

Two answers:

1)  I would put Mina in the category of lower level than even Netty.   
Probably doable, but would require a lot of work to write all the HTTP 
symantics onto it.   The "asyncweb" subproject of Mina could be a starting 
point, but that hasn't even had a commit to it in over 18 months and has 
never had a release.

2) Are you volunteering to look into it?   :-)



Dan



> 
> Jeff
> 
> On Jul 27, 2012, at 2:20 PM, Daniel Kulp wrote:
> > I've committed a few experiments I've been working on to:
> > 
> > https://svn.apache.org/repos/asf/cxf/sandbox/dkulp_async_clients
> > 
> > 
> > Basically, I've been trying to find an async client that is somewhat
> > usable for CXF without completely re-writing all of CXF.   Not exactly
> > an easy task.  For "POST"s, they pretty much are all designed around
> > being able to blast out pre-rendered content (like File's or byte[]).  
> > Doesn't really fit with CXF's way of streaming out the soap messages as
> > they are created.
> > 
> > My notes on 4 client API's I've played with:
> > 
> > 1) Ning/Sonatype Async Client:
> > http://sonatype.github.com/async-http-client/
> > (using Netty backend, didn't try the others)
> > 
> > This one really needed pre-rendered content.  When you can determine the
> > Content-Length up front, it's really not too bad.   However, once you
> > try to flip to Chunked, I just kept running into issues.  In the end, I
> > could not find an API that would let me us Chunked that actually
> > worked.   The one that looked like it should actually didn't write the
> > chunk headers out.  No idea what's up with it.  Got very frustrated
> > with it.
> > 
> > 2) Netty directly:  https://netty.io/
> > I did get the simple cases working with this fairly easily.  Seems quite
> > powerful and it actually performed really well.  The problem is that
> > it's
> > really very low level and doesn't provide a lot of things like
> > Keep-Alive
> > connection management "out of the box".  That's something we'd have to
> > write a lot of code to handle.  Not something I wanted to really
> > tackle.   That said, for small requests, Netty was the only one to
> > stick the HTTP headers AND the body into a single network packet.  
> > Even the URLConnection in the JDK doesn't do that.  Pretty cool.
> > 
> > 3) Jetty Client:  http://wiki.eclipse.org/Jetty/Tutorial/HttpClient
> > I did get this to work for most of my test cases.   There are definitely
> > a few "issues" that I think are likely bugs in Jetty, but easily worked
> > around.  For example, to get it to ask for chunks, you have to first
> > return an "empty" input stream.  Minor bugs asside, it did seem to work
> > OK. However, using the chunks did expose some issues on a raw network
> > side. Doing tcp dumps revealed that most of the chunk headers ended up
> > in their own TCP packets so it ended up taking a bit longer due to
> > extra packets transfered.  The other thing I didn't really like was it
> > kind of required much more byte[] copying than I really wanted.
> > 
> > 4) Apache HTTP Components (HC)- this was the first one I tried, ran into
> > performance issues, abandoned it to test the others, then came back to
> > it
> > and figured out the performance issue.  :-)   I had this "working", but
> > a
> > simple "hello world" echo in a loop resulted in VERY VERY slow
> > operation,
> > about 20x slower than the URLConnection in the JDK.   Couldn't figure
> > out
> > what was going on which is why I started looking at the others.   I came
> > back to it and started doing wireshark captures and discovered that it
> > was waiting for ACK packets whereas the other clients were not.   The
> > main issue was that the docs for how to set the TCP_NO_DELAY flag
> > (which, to me, should be the default) seem to be more geared toward the
> > 3.x or non-NIO versions. Anyway, once I managed to get that set, things
> > improved significantly.  For non-chunked data, it seems to be working
> > very well.  For chunked data, it seems to work well 99% of the time.  
> > It's that last 1% that's going to drive me nuts.  :-(   It's
> > occassionally writing out bad chunk headers, and I have no idea why.  
> > A raw wireshark look certainly shows bad chunk headers heading out.   I
> > don't know if it's something I'm doing or a bug in their stuff.  Don't
> > really know yet.
> > 
> > In anycase, I'm likely going to pursue option #4 a bit more and see if I
> > can figure out the last issue with it.
> > 
> > From a performance standpoint, for synchronous request/response, none of
> > them perform as well as the in-jdk HttpURLConnection for what we do.  
> > Netty came the closest at about 5% slower.  HC was about 10%, Jetty
> > about 12%. Gave up on Ning before running benchmarks.
> > 
> > However, as exected, the real win is when you use the JAX-WS async API's
> > to call onto a "slow" service.   (I only have the HC version working
> > for this at this point)   If you tune the connection pool to allow
> > virtually unlimmitted connections to localhost (mimics the
> > HttpURLConnection for comparison), it's pretty awesome.   I have a
> > simple service that uses the CXF continuations to delay for about 2
> > seconds on the server side to mimic some processing on the server side.
> >    5K async requests using the in-JDK stuff that we have using our
> > default thread pool settings and such takes about 35 seconds for all
> > the requests to complete.    With HC, I have that down to about 9
> > seconds.   However, that does require a bit of tuning of the HC
> > defaults and settings which is the next bit of complication.   Using
> > the async apis to call a "fast" (where response is returned very
> > quickly) service won't benefit as much.
> > 
> > In anycase, I've committed my experiments to the sandbox.   It does
> > require the latest trunk code for transport-http as well.   Any help or
> > thoughts or anything would be more than welcome.  :-)
-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Mime
View raw message