Grpc-dotnet: Why is SignalR/messagepack 2 times faster than gRPC/protobuf ?

Created on 6 Mar 2020  路  5Comments  路  Source: grpc/grpc-dotnet


I created an ASP/NET Core test app to compare gRPC/protobuf and SignalR/messagePack.

I tested with a C# client and with a web Javascript client using new expertimental grpc-web support. In both cases SignalR was approximately 2 times faster than gRPC(/Web).
My test simply replies an array of 100 structures. Each structure contains 5 mixed type properties and an array of 5 substructures containing 2 properties.

Both are using web-sockets on a fast local network. I expected protobuf marshalling to be faster.

question

Most helpful comment

Two things here:

  1. grpc-web adds some overhead to gRPC
  2. HTTP/2 is a heavier protocol than SignalR over websockets. SignalR has custom framing protocol that is optimized for what it needs, while HTTP/2 is very generic. For example, HTTP/2 is designed to multiplex multiple calls over a single TCP socket, while websockets is optimized for one caller.

In 5.0 we're working to optimize HTTP/2 in ASP.NET Core, and optimize the protobuf serialization. Expect gRPC performance to improve but not reach SignalR's performance.

All 5 comments

Two things here:

  1. grpc-web adds some overhead to gRPC
  2. HTTP/2 is a heavier protocol than SignalR over websockets. SignalR has custom framing protocol that is optimized for what it needs, while HTTP/2 is very generic. For example, HTTP/2 is designed to multiplex multiple calls over a single TCP socket, while websockets is optimized for one caller.

In 5.0 we're working to optimize HTTP/2 in ASP.NET Core, and optimize the protobuf serialization. Expect gRPC performance to improve but not reach SignalR's performance.

Curious: what kind of potential performance improvement we might see: single or double digit? I've always assumed that gRPC/Web is as close to theoretical minimum when it comes to Web related transports.

Are those expected improvements just by improving gRPC internal stuff or by some miracle browser vendors are thinking about exposing HTTP/2 api's for general use??

It isn't a matter of message size. The server implementation can be made faster.

What about latency?

I have run some benchmarks comparing gRPC to JSON to SignalR.

  • JSON: 48,000 RPS
  • gRPC: 59,000 RPS
  • gRPC bidi streaming: 115,000 RPS
  • SignalR bidi streaming: 80,000 RPS

Source

Note that this performance is between a .NET Core client and a .NET Core Server.

If you are calling from a browser with JSON/SignalR/gRPC-Web then expect significantly different performance results (although I'm not sure why you'd want to make thousands of requests per second from a browser).

As gRPC bidi streaming offers very good performance I think this issue can be closed.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

davidfowl picture davidfowl  路  6Comments

damienbod picture damienbod  路  6Comments

dariogriffo picture dariogriffo  路  5Comments

heartacker picture heartacker  路  3Comments

vuggg picture vuggg  路  3Comments