Hi,
I updated the benchmarking results.
I tested more simultaneous connections from 80 to 1000 connections.
Unfortunately it was not easy that I got meaningful data in many connections
because I used only one client machine.
But I was sure that Worker Thread IO and Leader Follower IO Strategy would
be more efficient than Same IO Thread Strategy in many connections.
In addition, my scenario doesn't have heavy business logic such as DB access
so jobs always returns the thread control to selector quickly. I think Same
IO Thread Strategy had the advantage over others in this scenario.
I attached results.
Thanks.
PS)
I was sure that Netty IO logic was similar to Grizzly's Same IO Thread
strategy because I could also see that Netty's CPU usages, thread counts and
etc... were very similar to Same IO Thread Strategy's and I also reviewed
Netty sources.
But for sure, I sent my question to Netty's community but I didn't receive
any answer yet.
Regards,
Bongjae Chang
From: Bongjae Chang <bongjae.chang_at_gmail.com>
Date: Tue, 06 Dec 2011 10:11:52 +0900
To: <dev_at_grizzly.java.net>
Subject: Re: Grizzly-Thrift benchmark results
Hi Alexey,
Ok. I will investigate Netty's IO logic more and test more connections(for
testing more connections, I think the client's test
program(ThriftClientBenchmark.java) should be fixed in order to use the same
transport in many connections).
And thank you for your changes of TGrizzlyClientTransport. :)
I will report results later.
Thanks.
Regards,
Bongjae Chang
From: Oleksiy Stashok <oleksiy.stashok_at_oracle.com>
Reply-To: <dev_at_grizzly.java.net>
Date: Mon, 05 Dec 2011 15:56:51 +0100
To: <dev_at_grizzly.java.net>
Subject: Re: Grizzly-Thrift benchmark results
Hi Bongjae,
thank you very much for the investigations and nice report!
Results look very good.
For sure it would be good to make sure Netty uses something like Grizzly
SameThreadStrategy, so we know we compare apples-to-apples, it would be also
interesting to see results for more simultaneous connections.
Thanks a lot!
WBR,
Alexey.
PS: I made some minor refactoring in the Grizzly thrift code, pls. let me
know if you're fine w/ that.
On 12/05/2011 11:27 AM, Bongjae Chang wrote:
>
> Added some data in conclusion.
>
>
>
>
> If you have any questions, please let me know!
>
>
>
>
> Thanks.
>
>
>
>
> Regards,
>
> Bongjae Chang
>
>
>
>
> From: Bongjae Chang <bongjae.chang_at_gmail.com>
> Date: Mon, 05 Dec 2011 15:49:58 +0900
> To: "dev_at_grizzly.java.net" <dev_at_grizzly.java.net>
> Subject: Grizzly-Thrift benchmark results
>
>
>
>
>
>
>
> Hi,
>
>
>
>
> I would like to share results.
>
> I attached the pdf and test sources.
>
>
>
>
> First, I used Grizzly's LeaderFollower IO Strategy in server side because LFIS
> had a bit performance improvement than Woker Thread IO Strategy and Grizzly's
> Same IO Strategy in only client side.
>
> But I found that Netty had better performance than Grizzly which used WTIS. So
> I also changed WTIS into Same Thread IO Strategy in server side and I found
> that Grizzly is best.
>
> It seemed that maybe Netty used the default IO logic like Grizzly's STIS when
> I reviewed the netty sources simply.
>
>
>
>
> In most of cases, Grizzly-thrift server and client modules were best. But in
> small packets, TSocket client had better performances.
>
>
>
>
> Thanks.
>
>
>
>
> Regards,
>
> Bongjae Chang
>
>
>