You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Willem jiang <wi...@gmail.com> on 2013/05/27 05:54:42 UTC
Netty transport for CXF
Hi,
As you know Netty[1] provides excellent supports of NIO and you can still get the full control of protocol handler. It could be useful if we provides a Netty transport of CXF.
I just did a prototype of support Netty transport for CXF, it include the server side implementation and client side implementation. And I did some performance compare tests by running the wsdl_first from examples with Jetty transport and Netty transport and using Jmeter to send the requests. The test results are much similar, Netty transport and Jetty transport can hit the highest processing recorder with the throughput of 9M per second in my MacBookPro. I only performance turning I did was just changing the thread pool size of ExecutionHandler which will be used to call the whole soap stake of CXF.
I'd like to commit the prototype into Apache CXF trunk, and we could polish the transport together :)
Any thought?
[1]http://netty.io/
--
Willem Jiang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
Re: Netty transport for CXF
Posted by Willem jiang <wi...@gmail.com>.
On Thursday, May 30, 2013 at 4:15 AM, Daniel Kulp wrote:
>
> On May 27, 2013, at 10:14 PM, Willem jiang <willem.jiang@gmail.com (mailto:willem.jiang@gmail.com)> wrote:
> > > > I just did a prototype of support Netty transport for CXF, it include the server side implementation and client side implementation. And I did some performance compare tests by running the wsdl_first from examples with Jetty transport and Netty transport and using Jmeter to send the requests. The test results are much similar, Netty transport and Jetty transport can hit the highest processing recorder with the throughput of 9M per second in my MacBookPro. I only performance turning I did was just changing the thread pool size of ExecutionHandler which will be used to call the whole soap stake of CXF.
> > >
> > >
> > >
> > > When I looked at Netty's HTTP client stuff (over a year ago now), I had MAJOR problems getting it to stream large messages. The small messages worked great and did have good performance, but once we could no longer buffer the whole message and wanted to get it streaming in chunks, I could never get it working. That said, that was a long time ago and they may have fixed all the bugs related to that.
> > The test that I did just one the server side and no chunk encoding involved.
> > We can polish it if we need :)
>
>
>
> Just checked. If the size of the message sent from the client exceeds the chunk threshold, nothing gets sent over the wire at all. :-( The client then just hangs and eventually times out. Didn't really look into what is needed yet.
I will dig this issue next week when I finish the SSL support of the netty.
>
>
> > > > I'd like to commit the prototype into Apache CXF trunk, and we could polish the transport together :)
> > > > Any thought?
> > >
> > >
> > >
> > >
> > >
> > > Sure. On the client side, if it's sticking to HTTP, I'd like to see it plug into the HTTPConduit like the async client version does. That's something we could work on though. Speaking of asyncclient version, they supposedly have a new version that is supposedly significantly faster. On my todo list to look at. :-(
> > Yes, it do the same thing as the async client does.
> > I will commit the code shortly today.
>
>
>
> We'll likely need to figure something out. With your changes to distribution, both async and netty clients are in the lib dir and it would then be whichever one is found on the classpath first.
>
I've been thinking about it for a while, maybe we should introduce some schemes as camel does, such as "abc", "netty", etc. if the client want to use async http client, he could specify the address with "ahc:http://example.com/server" and if he want to use netty he could use "netty:http://example.com/server", if he uses "http://example.com/server" we just let the class path decide which client will be used.
>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
--
Willem Jiang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
Re: Netty transport for CXF
Posted by Daniel Kulp <dk...@apache.org>.
On May 27, 2013, at 10:14 PM, Willem jiang <wi...@gmail.com> wrote:
>>> I just did a prototype of support Netty transport for CXF, it include the server side implementation and client side implementation. And I did some performance compare tests by running the wsdl_first from examples with Jetty transport and Netty transport and using Jmeter to send the requests. The test results are much similar, Netty transport and Jetty transport can hit the highest processing recorder with the throughput of 9M per second in my MacBookPro. I only performance turning I did was just changing the thread pool size of ExecutionHandler which will be used to call the whole soap stake of CXF.
>>
>> When I looked at Netty's HTTP client stuff (over a year ago now), I had MAJOR problems getting it to stream large messages. The small messages worked great and did have good performance, but once we could no longer buffer the whole message and wanted to get it streaming in chunks, I could never get it working. That said, that was a long time ago and they may have fixed all the bugs related to that.
> The test that I did just one the server side and no chunk encoding involved.
> We can polish it if we need :)
Just checked. If the size of the message sent from the client exceeds the chunk threshold, nothing gets sent over the wire at all. :-( The client then just hangs and eventually times out. Didn't really look into what is needed yet.
>>> I'd like to commit the prototype into Apache CXF trunk, and we could polish the transport together :)
>>> Any thought?
>>
>>
>>
>> Sure. On the client side, if it's sticking to HTTP, I'd like to see it plug into the HTTPConduit like the async client version does. That's something we could work on though. Speaking of asyncclient version, they supposedly have a new version that is supposedly significantly faster. On my todo list to look at. :-(
> Yes, it do the same thing as the async client does.
> I will commit the code shortly today.
We'll likely need to figure something out. With your changes to distribution, both async and netty clients are in the lib dir and it would then be whichever one is found on the classpath first.
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Netty transport for CXF
Posted by Willem jiang <wi...@gmail.com>.
Hi Dan,
Please check out my comments in line.
--
Willem Jiang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Tuesday, May 28, 2013 at 10:05 AM, Daniel Kulp wrote:
>
> On May 26, 2013, at 11:54 PM, Willem jiang <willem.jiang@gmail.com (mailto:willem.jiang@gmail.com)> wrote:
>
> > Hi,
> >
> > As you know Netty[1] provides excellent supports of NIO and you can still get the full control of protocol handler. It could be useful if we provides a Netty transport of CXF.
>
> Are you proposing some sort of proprietary Netty transport or are you thinking of using Netty's HTTP stuff to create another HTTP implementation for CXF?
It just leverage the Netty HTTP implementations.
>
>
> >
> > I just did a prototype of support Netty transport for CXF, it include the server side implementation and client side implementation. And I did some performance compare tests by running the wsdl_first from examples with Jetty transport and Netty transport and using Jmeter to send the requests. The test results are much similar, Netty transport and Jetty transport can hit the highest processing recorder with the throughput of 9M per second in my MacBookPro. I only performance turning I did was just changing the thread pool size of ExecutionHandler which will be used to call the whole soap stake of CXF.
>
> When I looked at Netty's HTTP client stuff (over a year ago now), I had MAJOR problems getting it to stream large messages. The small messages worked great and did have good performance, but once we could no longer buffer the whole message and wanted to get it streaming in chunks, I could never get it working. That said, that was a long time ago and they may have fixed all the bugs related to that.
The test that I did just one the server side and no chunk encoding involved.
We can polish it if we need :)
>
>
>
> > I'd like to commit the prototype into Apache CXF trunk, and we could polish the transport together :)
> > Any thought?
>
>
>
> Sure. On the client side, if it's sticking to HTTP, I'd like to see it plug into the HTTPConduit like the async client version does. That's something we could work on though. Speaking of asyncclient version, they supposedly have a new version that is supposedly significantly faster. On my todo list to look at. :-(
Yes, it do the same thing as the async client does.
I will commit the code shortly today.
>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
Re: Netty transport for CXF
Posted by Daniel Kulp <dk...@apache.org>.
On May 26, 2013, at 11:54 PM, Willem jiang <wi...@gmail.com> wrote:
> Hi,
>
> As you know Netty[1] provides excellent supports of NIO and you can still get the full control of protocol handler. It could be useful if we provides a Netty transport of CXF.
Are you proposing some sort of proprietary Netty transport or are you thinking of using Netty's HTTP stuff to create another HTTP implementation for CXF?
>
> I just did a prototype of support Netty transport for CXF, it include the server side implementation and client side implementation. And I did some performance compare tests by running the wsdl_first from examples with Jetty transport and Netty transport and using Jmeter to send the requests. The test results are much similar, Netty transport and Jetty transport can hit the highest processing recorder with the throughput of 9M per second in my MacBookPro. I only performance turning I did was just changing the thread pool size of ExecutionHandler which will be used to call the whole soap stake of CXF.
When I looked at Netty's HTTP client stuff (over a year ago now), I had MAJOR problems getting it to stream large messages. The small messages worked great and did have good performance, but once we could no longer buffer the whole message and wanted to get it streaming in chunks, I could never get it working. That said, that was a long time ago and they may have fixed all the bugs related to that.
> I'd like to commit the prototype into Apache CXF trunk, and we could polish the transport together :)
> Any thought?
Sure. On the client side, if it's sticking to HTTP, I'd like to see it plug into the HTTPConduit like the async client version does. That's something we could work on though. Speaking of asyncclient version, they supposedly have a new version that is supposedly significantly faster. On my todo list to look at. :-(
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com