In my last post, I presented a benchmark about performance in gRPC vs REST context. The results were very clear, gRPC in local macOS networks works better only for larger payloads. I decided to do the next step in this context & prepare a similar test environment in the Azure Kubernetes cluster.
To measure these results I decided to use Azure Application Insights requests monitor. Now I decided to use only four methods:
- Post/Failed – post requests finished with fail (500) (Failed / Post),
- Get – get only one element,
- GetColection – get a small collection of elements,
- Add – put requests.
This methods were implemented in both solutions:
Infrastructure of tests
- 16 pods of clients,
- 2 pods of server.
- 1200 requests per pod, per hour = 19200 requests/hour to 2 instances of the server.
Screenshots of results:
App Insights monitoring all gRPC requests like the POST method. Btw. without small modification of handling gRPC errors at server-side, all requests return 200! The way of handling of gRPC errors was presented here.
So as You see in almost production environments both ways of communication have very similar performance for small payload requests. Only error handling is 3 times faster in gRPC technology, but who wants to get handle errors faster :D?
2 thoughts on “Rest vs gRPC – performance benchmark in .Net Core 3.1 – Azure”
I haven’t done any benchmarking myself but I went through some articles with benchmarks and remember that grpc was much faster compared to rest. Maybe it depends on specific circumstances, numer of requests, software, hardware, network etc. Grpc is not human readable and slower to develop 🙂
Anyway, good read. Keep it up!
I tested it on the azure if I good rememberer. In.net 3.1 gRPC was only introduced. .Net 5.0 introduce some performance boots (if I good remember). But I was really surprised about this results. System.Text.Json is really fast – Deamon of Fast 😀