Performance Deep Dive: gRPC and REST

In the preceding article, we explored the advantages gRPC offers in comparison to conventional REST-based inter-service communication. On a theoretical level, gRPC stands out as the clear choice, suggesting it should be the new standard moving forward. Although I previously highlighted a few drawbacks, are these the only ones? Or are there other limitations or factors to consider before embracing gRPC for your application?

To address this question, I conducted comprehensive performance measurements to determine the scenarios and applications where gRPC outperforms REST. In this post, I present the details of my performance evaluation.

Sample Business Requirement

Consider a scenario where we aim to develop an application or service that provides product information. We have the option to request details about a specific product using its ProductId, or we can request a list of random products.

It’s important to note that this example is hypothetical, and actual real-world use cases might be more intricate.

Technical Setup

1. To implement these scenarios, I create two applications:

a. gRPC application server using Java, with two RPC methods:

• Get Product by Id
• Get Product List with given count

b. Similarly, created REST application using Java, Spring Boot and Spring Web with two APIs

• Get Product by Id
• Get Product List with given count

2. I have created 10,000 sample products data, with 30 attributes each and stored them into the application memory during the boot.

3. I have used Ubuntu docker container with default configuration, where no other process is running apart from our test application.

4. I have used Jmeter to performance test both applications. By default, Jmeter doesn’t have feature to test gRPCapplication, hence installed an external Jmeter-gRPC plugin to do that.

5. I am going to compare >90% response time and throughput as the factors to measure these applications technologies performance.

Let’s begin.

Performance Evaluation

Scenario#1: Response size < 1 KB

Let’s begin with the evaluation of our applications. To start with, I have used only 1 user to test to fetch single product and then started increasing the concurrent users in multiple of 10. The response payload size is approx. 800–900 B (~1 KB)

Observations:

· Response time (> 90%) is better with REST application initially, but at high user load gRPC become competent and works better.

· Throughput of gRPC application almost catches REST application as number of concurrent users increases.

Here are the competitive stats:

Scenario#2: Response Size ~70 KB

This time I have increased the response size by calling other endpoint to return list of 100 products. This way I got response size of around 70 KB. But this time too, observations was nearly same.

Observations

· Response time (>90%) and throughput both were good for a smaller number of concurrent users, but with higher load gRPC works better.

· It seems response size is not impacting much, rather user load is impacting the stats.

This way, if production applications expecting higher user load, then they should not use traditional REST (Spring Web) application. But replacing all REST application with gRPC is a good idea? Considering, the challenges and cons it comes with.

I think this comparison is between an expert and average candidate. I should bring in one more approach here.

Scenario#3: Bring In Spring Webflux too

As we are currently facing challenge due to number of users and that could be due to non-optimal handling of application threads in Spring Web. Earlier, I covered this analysis in detail here.

I decided to use Spring Webflux instead which is based on EventLoop and do better thread management and can handle more concurrent users.

Observations

As expected, Spring Webflux Application consistently performs way better than other two applications in terms of both Response Time and Throughput with response size < 100KB.

Also, Spring Webflux is more usable, supports traditional REST APIs implementation and which allow building compatible applications.

Now coming to original agenda, ‘gRPC is better compared to REST!’ To investigate further, I performed one more scenario.

Scenario#4: Response Size > 100 KB

This time I’ve increased the response size by asking application to give more that 500 products. I performed many tests run with varying size and result is now suggesting one clear winner.

Let’s see the stats first.

Observations

· Response time of gRPC application is better compared to other options, and this is certainly due to the Protobufand HTTP/2 being used behind the scene. That compresses the response size and also uses better network transmission mechanism.

· Throughput is better again due to better load handling by gRPC (which also uses EventLoop) and better network transmission using HTTP/2.

· I performed this test for higher data size till ~700 KB and result is in favor of gRPC all the way.

I have added all the measured numbers, stats and code here.

Conclusion

After all the test measurement and analysis, here are my recommendations:

· Use REST application based on Spring Web (Tomcat) for very light user load and small data size of ~1 KB. It will be great, if we don’t use this for critical production application.

· Use Spring Webflux or Eventloop based application to handle high user load, handling request/response size <100 KB. This will outperform others and also easier in integration and compatibility.

· Use gRPC application, when your application deals with high data size i.e., >100 KB. So, this way we can consider this for special types of application use case only. But, not fit for all.

On a high level for a data size > 100 KB

• gRPC woks ~50% faster compared with Spring Webflux and ~70 to 80% faster compared with Spring Web
• gRPC gives ~60 to 70 % higher throughput compared with REST applications.