I think you need to put an ample warning at the beginning of this article that this benchmark is only valid for such a small toy example, and it's not indicative of the actual performance of the protocols for a more common larger request body.
gRPC is famous for how fast the binary encoding and data transmission over long distances when compared to simple text encoding.
This is more apparent for larger requests and longer transmission.
Also, HTTP2 uses gRPC under the hood.
So it's only normal that if you found a toy example when gRPC is slower than HTTP1; even HTTP2 will be slower than HTTP1.
My experience tells me that in more common use cases, gRPC is faster than HTTP2 with JSON body, which is faster than HTTP1.
Another reason HTTP2 is faster than HTTP1 is the multiplexing of multiple requests over the same connection. HTTP2 solves the famous head of line blocking problem, but it's not tested in this benchmark.
A better benchmark for HTTP2 would have been the loading time of a web page with lots of resources from the same domain.
You're absolutely right that this benchmark focuses on a small example, and real-world performance can vary depending on factors like message size and complexity.
gRPC's strength in binary encoding and efficiency over long distances is a great point. I'll definitely add a section acknowledging this and emphasize that the benchmark is a starting point for exploration.
I want to add in a claim, saying "HTTP2 solves the famous head of line blocking problem" is wrong. The HOLB still exists at Transport layer in HTTP2, that's why they use QUIC in HTTP3.
Yeah, that would be interesting to dive deeper. It seems that their RPC is more designed for data workflows, while gRPC is more snappy service to service communication.
If you do such a benchmark I would really like to see it, if you don't forget and if I miss it please send me an email to radumarias@gmail.com with it :)
for me it seems that gRPG for Go is not very optimized. It should be much faster than JSON-messaging, being "precompiled". Parsing JSON in Go relies on dynamic reflection while gRPG uses generated code. In the end as shown in your benchmarks gRPG is not faster than JSON. And it produces the most garbage to be collected. GC could be one of the causes why gRPC performs not as espected.
Agree, there are ways to improve though. Custom JSON marshaller for example. I think the point of this article is not to assume things, but benchmark and improve for your own use case.
I forgot to add, this is a good example of how performance tests only gives a specific view of the world. If you want to choose a protocol for your application and performance is critical, you need to run your own benchmark for your specific use case.
why not try to benchmark in another languages if there's a known issue in Go?
I did a benchmark first only to learn later about the issue. If I find some time I may try to do it in other languages as well.
I think you need to put an ample warning at the beginning of this article that this benchmark is only valid for such a small toy example, and it's not indicative of the actual performance of the protocols for a more common larger request body.
gRPC is famous for how fast the binary encoding and data transmission over long distances when compared to simple text encoding.
This is more apparent for larger requests and longer transmission.
Also, HTTP2 uses gRPC under the hood.
So it's only normal that if you found a toy example when gRPC is slower than HTTP1; even HTTP2 will be slower than HTTP1.
My experience tells me that in more common use cases, gRPC is faster than HTTP2 with JSON body, which is faster than HTTP1.
Another reason HTTP2 is faster than HTTP1 is the multiplexing of multiple requests over the same connection. HTTP2 solves the famous head of line blocking problem, but it's not tested in this benchmark.
A better benchmark for HTTP2 would have been the loading time of a web page with lots of resources from the same domain.
Thanks Giuseppe, your points are well-taken!
You're absolutely right that this benchmark focuses on a small example, and real-world performance can vary depending on factors like message size and complexity.
gRPC's strength in binary encoding and efficiency over long distances is a great point. I'll definitely add a section acknowledging this and emphasize that the benchmark is a starting point for exploration.
I want to add in a claim, saying "HTTP2 solves the famous head of line blocking problem" is wrong. The HOLB still exists at Transport layer in HTTP2, that's why they use QUIC in HTTP3.
you are right. sorry for the confusion. Thanks a lot for highlighting my mistake above.
would be curious to see comparison with Apache Arrow Flight, that's also on gRPC https://arrow.apache.org/docs/format/Flight.html
Advantage of Arrow is it eliminates serialization
And combined that with RDMA I think the speed would be great (they have a feature request for this)
Yeah, that would be interesting to dive deeper. It seems that their RPC is more designed for data workflows, while gRPC is more snappy service to service communication.
If you do such a benchmark I would really like to see it, if you don't forget and if I miss it please send me an email to radumarias@gmail.com with it :)
they use gRPC in Flow, not custom one. The difference it makes the Arrow format as it doesn't to serialization on write/read over/from the wire
Hi Alex,
for me it seems that gRPG for Go is not very optimized. It should be much faster than JSON-messaging, being "precompiled". Parsing JSON in Go relies on dynamic reflection while gRPG uses generated code. In the end as shown in your benchmarks gRPG is not faster than JSON. And it produces the most garbage to be collected. GC could be one of the causes why gRPC performs not as espected.
Agree, there are ways to improve though. Custom JSON marshaller for example. I think the point of this article is not to assume things, but benchmark and improve for your own use case.
I forgot to add, this is a good example of how performance tests only gives a specific view of the world. If you want to choose a protocol for your application and performance is critical, you need to run your own benchmark for your specific use case.