Have you ever wondered how companies like Netflix handle large amounts of data and simultaneous API requests? Netflix is a globally recognized brand that manages enormous amounts of data to deliver video content to 235.69 million users (2023). For example, the company streams over 100 million hours of weekly video for a single popular Netflix television show.

The Netflix backend is primarily a collection of Java microservices designed to deliver content rapidly and reliably. gRPC is the communication protocol between the microservices. It acts like a language translation service, ensuring each part of the system understands each other.

Resource-intensive applications, like Netflix and bandwidth-limited applications, commonly use gRPC for more efficient communication. Now, Gatling has an official gRPC plugin for load testing.

The Gatling gRPC plugin is part of our dedication to supporting widely used REST, JMS, and MQTT technologies, making Gatling one of the most flexible testing tools. If you are currently using or considering gRPC for an upcoming project, Gatling Enterprise is an excellent solution for validating that your application can handle production-level traffic.

What is gRPC?

gRPC is an open-source framework and stands for google Remote Procedure Calls. gRPC uses protocol buffers for high-performance applications. gRPC is more performant than traditional HTTP request-response but requires HTTP/2 and is not directly compatible with web browsers. Features of gRPC include bidirectional streaming, authentication, and flow control. Use cases include mobile gaming and connecting microservices.

With gRPC, the server application and client share a service definition file, meaning that each "knows" the parameters and types, simplifying transactions. The client application calls the method on the server application, similar to calling a local object. This structure eases the creation of distributed applications and services.

Why is gRPC faster than traditional HTTP protocols? We need to understand how traditional HTTP protocols work to answer this question. One of the most common protocols is REST. If you read this blog post, you used a REST-based API today.  

REST works by sending a request and waiting for a response. The requests are commonly in the form known as JSON, a text-based data exchange format. The following is an example of a JSON set to the server: 

{
   "name": "Shaun B",
   "street number": 25,
   "street name": Broadway,
   "city": "New York City"
}

In contrast, gRPC transmits data in binary using Protobuf serialization (think 0s and 1s). If you aren’t a developer, this might seem abstract, so let’s use a real-world example to illustrate the concept.

Imagine you moved to a new address down the street. To keep getting deliveries from an e-commerce site, you visit their website to update your address. When you update your house number, say from 15 to 25, and click Update, your device sends the data to the company’s server. Now, let’s compare the size of the JSON and RPC messages: 

• In the JSON example, changing “25” to “15” and sending the update has a 9-byte payload (the size of the message).
•  With RPC, changing “25” to “15” the payload is 2 bytes. 

These payload sizes aren’t a big difference for small amounts of data, but when you start multiplying by billions or trillions of requests and responses, the efficiency of RPC can help make applications more performant. 

gRPC vs other protocols

Why load test gRPC?

Load testing your application is always a good practice, but with gRPC, there is a specific need due to connection management. 

gRPC channels individually use zero or more HTTP/2 connections, and each connection has a maximum amount of concurrent streams. If the number of active RPCs hits the concurrent streams' maximum, the client starts queuing until the completion of the active RPCs. 

Thus, high load or long streams can cause performance degradation. You can establish the limits of your current application and define possible improvements using load testing.

The Gatling gRPC plugin

The Gatling gRPC plugin supports testing applications and microservices that use gRPC. The plugin is available under the Gatling Enterprise component license: 

• The libraries published on Maven Central use a commercial license that forbids decompilation and modification. The intent of these libraries is for crafting and debugging tests locally. Built-in limitations, such as a 5-minute test duration, enforce the crafting and debugging intention. 
  
  
• The unlimited version of the plugin is only available when executing load tests on Gatling Enterprise.

An existing community plugin developed by George Lung allows users to test gRPC protocol buffers with tests written in Scala. George’s plugin inspired our plugin.

The primary differences are that we wanted to integrate this capability into the core Gatling product, support Java and Kotlin, and use code familiar to non-Scala developers. 

Best practices for gRPC load testing

The Gatling gRPC plugin provides comprehensive support for implementing these best practices, allowing software engineers to validate that their distributed applications can handle production-level traffic with proper load balancing and resource management.

When configured correctly, gRPC applications can maintain high performance even with multiple concurrent streams and complex protocol buffer implementations.

1. Define clear metrics: Set specific targets for requests per second, response times, and error rates before testing.
2. Test all communication types: Include unary RPC, server streaming, client streaming, and bidirectional streaming in your tests.
3. Use realistic scenarios: Create test cases that mirror your production traffic patterns and data sizes.
4. Monitor both sides: Track client metrics (latency, throughput) and server metrics (CPU, memory usage) during testing.
5. Test with various loads: Start with expected load, gradually increase to identify breaking points, and measure recovery time.
6. Verify error handling: Test timeout scenarios and retry logic to ensure graceful failure handling.
7. Automate testing: Integrate performance testing into your CI/CD pipeline to catch regressions early.

How to get started

The best way to get started is to download one of our gRPC demo projects from GitHub. If you have an existing project and want to enable the gRPC plugin, the Gatling Documentation provides a detailed setup procedure.  

If your application uses gRPC and you want to incorporate grpc testing, contact one of our specialists to arrange a demo: