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.
Two things here:
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.
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.
Most helpful comment
Two things here:
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.