Why gRPC is high-performance?

gRPC is designed to be efficient and fast, it’s suitable for distributed systems where performance is crucial.

But if you ask why is that? I’d say for 2 reasons gRPC is high-performance.

Reason 1: Using HTTP/2.0

image

HTTP/2 introduces several features such as multiplexing, header compression, and server push, which significantly enhance the performance of communication between clients and servers. Multiplexing allows multiple requests and responses to be sent and received asynchronously over a single TCP connection, reducing latency and improving throughput.

HTTP/1.1 introduced request pipelining where the clients can fire multiple requests to the server before receiving the response within the same TCP connection, but it did not allow multiple responses to be multiplexed on the same connection forcing each response to be returned sequentially. This phenomenon is called HoL (Head-of-Line) blocking.

HTTP/2.0 fixed HOL by streaming both requests and responses.

Reason 2: Using Protobuf

benchmark

gRPC uses Protocol Buffers (Protobuf) as its default serialization mechanism. Protobuf is a binary serialization format that is more compact and faster to serialize and deserialize compared to text-based formats like JSON or XML. This efficiency contributes to better performance.

Source code for the benchmark: Github-C# Serializers

Want to be practical on gRPC, check out these 2 videos:

gRPC in ASP.NET Core: https://youtu.be/SgCAPjyotLM

Protobuf vs 5 other C# serializer: https://youtu.be/qWacutAW3e8

2
An error has occurred. This application may no longer respond until reloaded. Reload x