What About gRPC Testing?

In this article, I will try to dispel the myth that testing gRPC is difficult and not interesting. Let's go!

gRPC (Remote Procedure Calls) is an open source Remote Procedure Calling (RPC) system originally developed at Google in 2015. HTTP/2 is used as the transport, and Protocol Buffers is used as the interface description language.

Basically, the use of RPC is communicating between microservices and building communication with the server.

The main differences between gRPC and REST.

Connection speed and support for streams - for me, these are the main advantages.

There are a few differences between the gRPC API and REST.

As a variant of the RPC architecture, gRPC was created by Google to speed up data transfer between microservices and other systems that need to interact with each other. Compared to the REST API, the RPC API is unique in the following ways:

• Built on HTTP 2 instead of HTTP 1.1
• Protobuf instead of JSON
• Creating your own code instead of using third-party tools like Swagger
• Longer implementation than REST
• Message transmission is 7-10(!) times faster

Glossary

• proto file is a message format in which I describe all the methods and services that this service provides. Specification.
• channel is a connection. by analogy with host.
• stub client that has methods for responding, just stub.
• Reflection is a feature in gRPC that allows a list of methods or services to work with on a remote machine. Sometimes you can also request an example message.

BloomRPC. Good for a start.

Let's move on to testing. The main tool for testing gRPC for me is BloomRpc. It is quite simple and clear.

First, you need to import the proto file into bloomRpc. To do this, click on the plus sign.

Then, select the required proto file and add it. After that, our proto file will appear in the left menu, which has a method and services.

By clicking on the green launch button, you will actually send a request. It's simple.

Actually, with this, the main functionality of the application comes to an end. Most of all, it seems to me that reflection is missing here. You can try it with the insomnia app. But we'll discuss this later in upcoming articles.

A great way to load.

I also want to share a fairly fast method for gRPC load testing.

It is always good to check it for throughput when launching a new service.

After all, this is how we can avoid the so-called bottlenecks of our service.

Ideally, of course, I would like to see that our services can withstand the loads required of them and the throughput does satisfy us.

But practice shows that this does not always happen, and checking the load with this tool will save you time and the company money.

GHZ

Let's start the gRPC load testing with the GHz console application.

Direct quote from the website GHz:

ghz is a command line utility and Go package for load testing and benchmarking gRPC services. It is intended to be used for testing and debugging services locally, and in automated continous intergration environments for performance regression testing.

Additionally the core of the command line tool is implemented as a Go library package that can be used to programatically implement performance tests as well.

Let's disassemble each step.

A special command is used to call - ghz

Step 1.

--proto ./my.proto \

--proto The Protocol Buffer .proto file

Step 2.

--call helloworld.my.SayHello \

A fully-qualified method name in 'package.Service/method' or 'package.Service.Method' format.

Step 3.

-d '{"name":"Ruslan"}' \

-d The call data as stringified JSON. If the value is '@', then the request contents are read from stdin.

Step 4.

Specify the address. Launch.

Total

The sample request of the basic test for the load looks like this. This will be quite enough for a routine check.

ghz --proto ./my.proto \
  --call helloworld.my.SayHello \
  -d '{"name":"Ruslan"}' \
  0.0.0.0:3000

After running such a command, a response will be returned. In the cat, you can see the detailed results of load testing on our proto service.

I also recommend that you set up a graphana for your service, so you can compare the load from the tool and the performance of your service.

Thank you for your time, that is all.