DEV Community

Thang Chung
Thang Chung

Posted on

Performance benchmark: gRPC vs. REST in .NET Core 3 Preview 8

Recently, I have used gRPC and REST in the same host on my project. And I always wonder what if I can know at least what makes different between gRPC and REST when I do the inter-communication between services inside a Kubernetes cluster.

Alt Text

I have found the blog about the performance benchmark written by Ruwan Fernando. That was awesome, and that's clear after spent sometimes to have a look the code-based. I decide to fork it and write out some more code for .NET Core Preview 8 to see how different between gRPC and REST protocol in this new SDK which is published by Microsoft and also using it for my project.

Let run the benchmark as following

$ dotnet run -p RestAPI.csproj -c Release
Enter fullscreen mode Exit fullscreen mode
  • gRPC API:
$ dotnet run -p GrpcAPI.csproj -c Release
Enter fullscreen mode Exit fullscreen mode
  • Benchmark project:
$ dotnet run -p RESTvsGRPC.csproj -c Release
Enter fullscreen mode Exit fullscreen mode

Now, what we can do is waiting until it finished. And we will have a result as below

Alt Text

When you get the small data with REST, then it is quite faster than gRPC

$ RestGetSmallPayloadAsync |            100 |    14.99 ms |  0.2932 ms |  0.2743 ms |
Enter fullscreen mode Exit fullscreen mode
$ GrpcGetSmallPayloadAsync |            100 |    19.60 ms |  0.3096 ms |  0.2896 ms |
Enter fullscreen mode Exit fullscreen mode

This is I think because .NET Core team has already optimized the performance of JSON processing in the core. But it is not effective if we run with the large data with REST. See below

$ RestGetLargePayloadAsync |            100 | 1,181.00 ms | 13.9860 ms | 12.3982 ms |
Enter fullscreen mode Exit fullscreen mode
$ GrpcGetLargePayloadAsListAsync |            100 |   187.93 ms |  1.7881 ms |  1.6726 ms |
Enter fullscreen mode Exit fullscreen mode

You can see how different gRPC vs. REST when we deal with the big chunk of data.


.NET Team makes a huge difference when dealing with small data in the payload of the message, but actually with the large payload of data, the different has gone. gRPC is still a winner in this area. I'm not saying which one is better than another. What I'm going to say is we need the appropriate strategy for using what kind of protocol with your business cases.

I usually use REST communication in outside communication with the external world such as external service integration, communication with front-end... And the whole communication inside the Kubernetes is all about gRPC because of power that we have with HTTP/2. I know that we can configure HTTP/2 with REST on the Kestrel as well, but it comes with a cost and ineffective because we need to maintain the cert in Kestrel. Otherwise, we normally offload inside the Kubernetes cluster to make it simple and fast for the performance in communication.

I love what Kubernetes architecture used the payload format for the transport protocol as following

Alt Text

The source code can be found at, and the original code-based at


Top comments (1)

plutov profile image
Alex Pliutau

We also did our fair benchmark with Go examples to compare Protocol Buffers over gRPC vs. JSON over HTTP/1 and HTTP/2. The results are very interesting -