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.

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

• REST API:

$ cd RESTvsGRPC\RestAPI
$ dotnet run -p RestAPI.csproj -c Release

• gRPC API:

$ cd RESTvsGRPC\GrpcAPI
$ dotnet run -p GrpcAPI.csproj -c Release

• Benchmark project:

$ cd RESTvsGRPC\RESTvsGRPC
$ dotnet run -p RESTvsGRPC.csproj -c Release

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

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 |

$ GrpcGetSmallPayloadAsync |            100 |    19.60 ms |  0.3096 ms |  0.2896 ms |

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 |

$ GrpcGetLargePayloadAsListAsync |            100 |   187.93 ms |  1.7881 ms |  1.6726 ms |

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

Summary

.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

The source code can be found at https://github.com/thangchung/RESTvsGRPC, and the original code-based at https://github.com/EmperorRXF/RESTvsGRPC

References:

• https://medium.com/@EmperorRXF/evaluating-performance-of-rest-vs-grpc-1b8bdf0b22da
• https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel
• https://gooroo.io/GoorooTHINK/Article/16623/One-Weird-Trick-To-Improve-Web-Performance/21564#.Vx9o5UdkldB
• https://devblogs.microsoft.com/aspnet/asp-net-core-2-2-0-preview1-http-2-in-kestrel/
• https://kubernetes.io/blog/2018/07/18/11-ways-not-to-get-hacked/