How to Test Performance of gRPC
Software interfaces were invented to integrate applications. They work as a kind of port through which you can connect to third-party software and interact with it, for example, send a request to a database and get a response. To make the interface usable for other software, there have to be some rules—what requests can be sent to the application and what the responses will be.
Several standard platforms and protocols are used to create software interfaces. One of the most well-known systems is REST API, based on a popular Internet protocol HTTP. However, there are other ways to organize communication between applications, and one of them is the gRPC framework.
gRPC is a platform that helps create software interfaces based on Remote Procedure Call (RPC). gRPC was originally developed by Google but was later converted to open-source software. Unlike REST API, the system allows third-party subprograms to run as if they were run locally, although in fact they may be running on a different computer. This approach is faster and simpler than traditional HTTP requests.
The API created with gRPC consists of a server and a client. The client generates procedure calls, and the server processes them. There may be a variety of such interactions, as gRPC initially supports different programming languages and lets clients of different applications communicate with the server. Architectural differences provide a framework with a speed higher than in REST API. The thing is, the messages exchanged by applications under gRPC are smaller. In addition, HTTP/2 allows a full-fledged, bidirectional flow of data exchange, instead of acting in the “request-response” paradigm, as in HTTP 1.1.
No matter how fast and progressive gRPC is, do not forget to check its speed. If the API is not working well, you may lose some requests, along with some users of your application. Therefore, it is important to regularly check performance by defining API benchmarks, which include:
- Average and maximum delay of a single request sent by a single client;
- Number of queries per second (QPS) sent by a pair of clients using 64 bidirectional channels and a 100-message stack;
- QPS per a processor core.
The main difference between gRPC performance testing and that of other parts of an application or site is the necessity to check the complete two-way data exchange. Its analysis requires special methods and tools, because the testing involves two parties. It is important not only to check the ability of the server to handle many requests from the client, but also the client’s ability to “digest” the data stream from the server. We have selected the best gRPC performance testing tools for you.
Gatling is a popular load testing tool with both proprietary and open-source versions. One of its features is its own subject-oriented language for creating test scenarios. Open architecture allows connecting custom plugins that extend the functionality of the system. To test gRPC interfaces, there is a free Scala plugin.
The plugin allows you to run the following tests:
- Sending single requests from the client to the server and getting responses to them
- Sending streaming requests from the client to the server and waiting for the response
- Streaming messages from the server to the client
- Bidirectional data flow between the client and the server
In all the tests, Gatling measures the reaction time of the tested component by noting thresholds and averages. The test results are presented as graphs and illustrated charts.
In k6, you can run load tests based on scripts written in Java. You can choose a free open-source utility for local testing or connect to a cloud SaaS service. Scripts are universal and will work in both cases. k6 lets you emulate different geolocations, as well as perform other types of testing, apart from performance:
- End-to-end web testing using different browsers
- Random testing emulating real traffic
- Cloud infrastructure scalability testing
- Regression testing
Starting with version 0.29.0, k6 includes a gRPC testing module that can generate single requests from the client to the server. Streaming testing is in the roadmap of k6 development, but so far the system does not provide such a possibility.
Apache JMeter is a universal tool for testing local applications and web resources. It can be used to simulate users working with a single server or a group of servers, a network, or different software. JMeter is written in Java and is open-source software, so third-party developers can complement its functionality with their own plugins. One of these additional modules implements gRPC test scenarios.
An interesting feature of the plugin is its ability to compare gRPC and REST API interfaces. This way you can check which of the methods of integration with external applications is better for your development. Unfortunately, this is also a weak point of the test—it focuses on estimating the delay of processing single requests, but does not check the bandwidth of the data exchange channel during streaming.
Another open-source load testing system, Locust, makes it possible to describe user behaviors in Python without using what the system designers consider to be cumbersome user interfaces. Load tests can be distributed across multiple servers, allowing for the emulation of multiple concurrent users.
Since Locust is intended as a means to create tools rather than a ready-made tool, to run a gRPC load test, you will need to develop a script in Python or adapt the script of another developer for your purposes. As you can guess, the functionality of this test will be limited only by your imagination and… knowledge of Python.
PFLB cloud platform offers user-friendly and efficient load testing tools that are suitable both for large web resources with a distributed server system and for a stand-alone application with its first release still in the future. Working with PFLB does not require any special knowledge or programming skills—all tests can be modeled in an intuitive graphical interface in just a few clicks.
We have added gRPC support to our service list. Now you can also check the speed of the software interface based on the remote procedure call with PFLB. The capabilities of the system make it possible to simulate different load test scenarios, and get comprehensive information about potential problems with recommended solutions. Try it yourself, and if you need help, we are always there for you!