gRPC Proto3 performance vs Apache thrift perfomance

[Udit Sharma]

i am playing for sometime  with sample apps written in both framework in java.

And here is response times i observed.

Thrift : 404 ms for 10K sequential RPC calls .

GRPC =  4478 ms for 10K sequential  RPC calls.

I am surprised with this result, i was not expecting this at all. I may be doing something wrong, so just wanted to check, if this results make sense at all ? 

Can someone help me understand what might be going behind the scene which can explain this ? 

http://pastebin.com/5tUB3F2m (link to sample app code for the client)

[Louis Ryan]

A few things jump out that you'll want to look at...

- Make sure GRPC does not have TLS enabled

- When creating your server call ServerBuilder.directExecutor  (We don't usually recommend this for real world usage as it makes the network thread block on application code but that's what you're doing with Thrift so....)

- Similarly use ManagedChannelBuilder.directExecutor (Same issue as above)

Also your benchmarks have no warm up phase which is going to mess with your numbers. Use a real benchmarking framework like JMH to drive things.

GRPC is doing more work than Thrift that comes at a cost, the metadata exchange features are a built-in for GRPC that Thrift does not have

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/8ac14b21-17bc-4d70-b61d-0f11ec0af48e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[chad_w...@yahoo.com]

"GRPC is doing more work than Thrift that comes at a cost, the metadata exchange features are a built-in for GRPC that Thrift does not have"

Can you elaborate on this comment a bit? I am evaluating gRPC performance and I would like to understand this at an architectural level.

Thanks,

Chad Walters

Microsoft Corp.

On Friday, September 30, 2016 at 9:22:08 AM UTC-7, Louis Ryan wrote:

A few things jump out that you'll want to look at...

- Make sure GRPC does not have TLS enabled

- When creating your server call ServerBuilder.directExecutor  (We don't usually recommend this for real world usage as it makes the network thread block on application code but that's what you're doing with Thrift so....)

- Similarly use ManagedChannelBuilder.directExecutor (Same issue as above)

Also your benchmarks have no warm up phase which is going to mess with your numbers. Use a real benchmarking framework like JMH to drive things.

GRPC is doing more work than Thrift that comes at a cost, the metadata exchange features are a built-in for GRPC that Thrift does not have

On Fri, Sep 30, 2016 at 6:31 AM, Udit Sharma <udit...@gmail.com> wrote:

i am playing for sometime  with sample apps written in both framework in java.

And here is response times i observed.

Thrift : 404 ms for 10K sequential RPC calls .

GRPC =  4478 ms for 10K sequential  RPC calls.

I am surprised with this result, i was not expecting this at all. I may be doing something wrong, so just wanted to check, if this results make sense at all ? 

Can someone help me understand what might be going behind the scene which can explain this ? 

http://pastebin.com/5tUB3F2m (link to sample app code for the client)

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.

To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.

[Louis Ryan]

On Tue, Oct 25, 2016 at 11:28 AM, chad_walters via grpc.io <grp...@googlegroups.com> wrote:

"GRPC is doing more work than Thrift that comes at a cost, the metadata exchange features are a built-in for GRPC that Thrift does not have"

Can you elaborate on this comment a bit? I am evaluating gRPC performance and I would like to understand this at an architectural level.

GRPC protocol is roughly:

Request -> <Headers> <Message> <End>

Response -> <Headers> <Message> <Trailers> <End>

Thrift is simply

Request -> <Message> <End>

Response ->  <Message> <End>

Moving headers and trailers around comes with a cost but it provides a standard mechanism for API agnostic metadata to be exchanged and for frameworks to inject/receive that metadata. Metadata exchange is critical to a serviceable API framework.

GRPC uses HTTP2 at the transport layer which is a multiplexing wire protocol, this comes with a framing overhead but provides a variety of benefits at the same time (flow-control, mid-stream cancellation, no need to open many sockets which avoids exploding TLS negotiation costs and saves file descriptors. It will also transit standard HTTP2 proxies which Thrift will not.

In Java Thrift typically uses a thread per socket with blocking reads and writes, this comes with pretty hard scaling limits. You can use Thrift in an async manner I think, at which point it's performance converges with GRPC but without the aforementioned benefits.

 

To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/b5736ff4-6a09-4f6d-be6a-09016f5bffd5%40googlegroups.com.