Hi,
I spent some time to look at the code.
In general it looks correct. The important difference is that RPC's
GrizzlyProtocolFilter implementation is not doing the same as for
example Netty. GrizzlyProtocolFilter always parses just one message from
a source Buffer and passes it upstream for processing, which seriously
hits memory consumption. For example RPC's NettyProtocolFilter is able
to parse and pass upstream *all* messages available in the Buffer.
I fixed that part (a bit dirty for now), and have a note to improve
existing Grizzly API :)
Also I made another optimization in GrizzlyServerHander to buffer output
data, when we're processing several requests in the loop, and flush the
data once all the requests processed.
After making mentioned changes, Grizzly server became faster than others.
Grizzly: Avg TPS: 58760 Max TPS: 62100 Min TPS: 54845
Netty: Avg TPS: 55377 Max TPS: 56989 Min TPS: 53022
Results are taken on my laptop using *Netty* client (for both servers)
with settings you mentioned in the prev. email.
As for the Grizzly client side... Grizzly asynchronous write queue
implementation is not optimized for your usecase. I need a bit more time
to fix it. Will let you know asap.
Thanks!
WBR,
Alexey.
On 09/09/2011 05:48 AM, BlueDavy Lin wrote:
> hi!
>
> I intergrate grizzly to my rpc framework,and do benchmark for
> netty/mina/grizzly,the result is:
> 100 concurrents,100 bytes request size,single connection,sync
> call (500ms timeout),hessian serialize
> mina: 102k
> netty: 148k
> grizzly: 62k
>
> I think maybe I use grizzly wrong,can someone help me to see
> what can I do to tune grizzly performance,u can see code at here:
> http://code.google.com/p/nfs-rpc/source/checkout
>