Hi Bongjae,
> I updated the benchmarking results.
Thanks a lot!
> 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.
AFAIR we saw similar results w/ HTTP server testing, Worker-thread
strategy was slightly better.
> 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'm not sure it's important to make tests, which involve heavy business
logic, cause our goal is to test transport, not DB access :)
> I think Same IO Thread Strategy had the advantage over others in this
> scenario.
IMO it can be opposite. When using STS, heavy business logic or blocking
DB access can block selector thread -> block all the connections
registered on the selector. I'd say worker thread strategy should fit
better for such a tasks.
Just my opinion :)
> I attached results.
Thank you!!!
It would be great to have a blog on that.
WBR,
alexey.
>
> 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
> <mailto:bongjae.chang_at_gmail.com>>
> Date: Tue, 06 Dec 2011 10:11:52 +0900
> To: <dev_at_grizzly.java.net <mailto: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
> <mailto:oleksiy.stashok_at_oracle.com>>
> Reply-To: <dev_at_grizzly.java.net <mailto:dev_at_grizzly.java.net>>
> Date: Mon, 05 Dec 2011 15:56:51 +0100
> To: <dev_at_grizzly.java.net <mailto: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
>> <mailto:bongjae.chang_at_gmail.com>>
>> Date: Mon, 05 Dec 2011 15:49:58 +0900
>> To: "dev_at_grizzly.java.net <mailto:dev_at_grizzly.java.net>"
>> <dev_at_grizzly.java.net <mailto: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
>