Hi Alexey,
Alexey wrote:
> 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.
You're telling me!
Alexey wrote:
>It would be great to have a blog on that.
Ok. I will try it.
Thanks!
Regards,
Bongjae Chang
From: Oleksiy Stashok <oleksiy.stashok_at_oracle.com>
Reply-To: <dev_at_grizzly.java.net>
Date: Wed, 07 Dec 2011 10:39:41 +0100
To: <dev_at_grizzly.java.net>
Subject: Re: Grizzly-Thrift benchmark results
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>
> 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
>>
>>
>>
>
>
>
>
>
>