Tag: gRPC

gRPC is a bery efficient form of communication between different servers.

In the past each programming language had its own technique of Remote Invocation using a very efficient binary serialization and de-serialization. But then these services are not compatible across programming languages. Then webservices standards such as SOAP based on XML, REST API’s based on XML or JSON have evolved. SOAP and REST API’s are a standard and can be implemented in different programming languages. Even now, REST based API’s are the most popular choice. Now comes gRPC alleviating the problems and offers very high performance, development tools are shared across different programming languages and takes advantage of HTTP/2, HTTP/3 where possible.

gRPC re-uses server connections and offers significant advantages in terms of performance i.e the overhead of establishing and disconnecting connections gets minified. Efficient serialization and de-serialization offers high performance in terms of payload and speed i.e fewer CPU cycles and fewer network bytes.

The following tips are for .Net platform:

1. Increase connection concurrency limit i.e by default the concurrency limit is 100, on large servers with many connections, if you see a performance hit i.e gRPC calls getting queued, consider increasing the concurrency limit.
2. Enable SocketsHttpHandler.EnableMultipleHttp2Connections = true;
3. Consider client side load balancing where applicable, server side load balancing adds a little extra latency, because the request reaches the load balancer and then gets routed to a server. With client side load balancing the client knows how to communicate with the different servers and sends requests appropriately removing the overhead of extra latency.
4. If the service’s gRPC messages are larger than 96kb consider increasing the InitialConnectionWindowSize and InitialStreamWindowSize.

Latest versions of .Net support creating REST based API’s and gRPC based services with the same code – a topic for a different blog post, but definitely a reason to start using gRPC.

–

Mr. Kanti Kalyan Arumilli

B.Tech, M.B.A

Facebook

LinkedIn

Threads

Instagram

Youtube

Founder & CEO, Lead Full-Stack .Net developer

ALight Technology And Services Limited

ALight Technologies USA Inc

Youtube

Facebook

LinkedIn

Phone / SMS / WhatsApp on the following 3 numbers:

+91-789-362-6688, +1-480-347-6849, +44-07718-273-964

+44-33-3303-1284 (Preferred number if calling from U.K, No WhatsApp)

kantikalyan@gmail.com, kantikalyan@outlook.com, admin@alightservices.com, kantikalyan.arumilli@alightservices.com, KArumilli2020@student.hult.edu, KantiKArumilli@outlook.com and 3 more rarely used email addresses – hardly once or twice a year.

In the past, I have written about a little known utility for collecting metrics known as CollectD. CollectD samples various metrics at configured interval and outputs to various destinations. This particular blog post is about having CollectD send the metrics to a GRPC endpoint, the endpoint can decide how to further process the received data. In this blog post, I would be writing about C# GRPC server for receiving data, but in reality most programming languages that support GRPC can be used.

One more thing, having CollectD use GRPC is slightly complex, because several different libraries need to be installed. Here is a list for Ubuntu, this is not an exhaustive list, but the list of libraries that I had to install on Ubuntu to allow CollectD report metrics using GRPC – gcc, gpp, build-essential, protobuf-compiler-grpc, libprotobuf-dev, protobuf-compiler, libgrpc++-dev. The best way to find any missing libraries is to compile CollectD from source as mentioned in https://collectd.org/download.shtml, and after ./configure look for missing libraries beside grpc until the output shows grpc – yes.

Now for the C# server, here is the .proto file, I have used:

syntax = "proto3";

package collectd;

import "google/protobuf/duration.proto";
import "google/protobuf/timestamp.proto";

service Collectd {
  rpc PutValues(stream PutValuesRequest) returns(PutValuesResponse);
}

message PutValuesRequest {
  ValueList value_list = 1;
}

message PutValuesResponse {}

message Identifier {
  string host = 1;
  string plugin = 2;
  string plugin_instance = 3;
  string type = 4;
  string type_instance = 5;
}

message Value {
  oneof value {
    uint64 counter = 1;
    double gauge = 2;
    int64 derive = 3;
    uint64 absolute = 4;
  };
}

message ValueList {
  repeated Value values = 1;

  google.protobuf.Timestamp time = 2;
  google.protobuf.Duration interval = 3;

  Identifier identifier = 4;

  repeated string ds_names = 5;
}

The .proto file is largely based on the proto files available at https://github.com/sandtable/collectd-grpc.

The implementation for the C# server is very simple. I have set the protobuf compiler to only generate the server side code. Create class that inherits from CollectdBase. Override the method PutValues. Remember the request is a stream.

public override async Task<PutValuesResponse> PutValues(IAsyncStreamReader<PutValuesRequest> requestStream, ServerCallContext context)
{
    while (await requestStream.MoveNext())
    {
        var currentItem = requestStream.Current;
        //Do something with currentItem
    }

    return new PutValuesResponse();
}

–

Mr. Kanti Kalyan Arumilli

B.Tech, M.B.A

Facebook

LinkedIn

Threads

Instagram

Youtube

Founder & CEO, Lead Full-Stack .Net developer

ALight Technology And Services Limited

ALight Technologies USA Inc

Youtube

Facebook

LinkedIn

Phone / SMS / WhatsApp on the following 3 numbers:

+91-789-362-6688, +1-480-347-6849, +44-07718-273-964

+44-33-3303-1284 (Preferred number if calling from U.K, No WhatsApp)

kantikalyan@gmail.com, kantikalyan@outlook.com, admin@alightservices.com, kantikalyan.arumilli@alightservices.com, KArumilli2020@student.hult.edu, KantiKArumilli@outlook.com and 3 more rarely used email addresses – hardly once or twice a year.

REST – Representational State Transfer is the most common way of data communication and is based on HTTP 1.1. The data format are generally XML or JSON. HTTP Status codes are usually used for statuses, and sometimes the payload has the statuses.

gRPC – Google’s Remote Procedure Call is a more modern method and based on HTTP 2. Due to HTTP 2 some older software or browsers might not have support. But, gRPC is the way forward. The advantages are several, I am mentioning some of the advantages here:

1. High performance serializer and deserializer based on protobuf binary format.
2. The data size is much lesser compared with JSON / XML.
3. Server to client communication (based on existing connection), Client to server communication, Streaming from Server to Client (on existing connection), Streaming from Client to Server and even duplex communication.
4. Efficient usage of networking i.e because gRPC is based on HTTP 2, network connections need not be opened for every call.

.Net has fully embraced and supports modern code generation for gRPC. In further blog posts, I will explain and provide some code samples for using gRPC in .Net.

I personally have not performed any speed tests trying to compare REST vs gRPC but, I did use gRPC in some micro-service architecture application and found the performance of gRPC significantly higher than REST.

–

Mr. Kanti Kalyan Arumilli

B.Tech, M.B.A

Facebook

LinkedIn

Threads

Instagram

Youtube

Founder & CEO, Lead Full-Stack .Net developer

ALight Technology And Services Limited

ALight Technologies USA Inc

Youtube

Facebook

LinkedIn

Phone / SMS / WhatsApp on the following 3 numbers:

+91-789-362-6688, +1-480-347-6849, +44-07718-273-964

+44-33-3303-1284 (Preferred number if calling from U.K, No WhatsApp)

kantikalyan@gmail.com, kantikalyan@outlook.com, admin@alightservices.com, kantikalyan.arumilli@alightservices.com, KArumilli2020@student.hult.edu, KantiKArumilli@outlook.com and 3 more rarely used email addresses – hardly once or twice a year.