Optimizing gRPC for localhost

[Gautham Banasandra]

Hi all,

I'm using gRPC to communicate between a go and C++ process running on the same node. The C++ process hosts the gRPC server and the go process is the client. The go process makes a lot of gRPC calls hosted by the gRPC server in the C++ process in a blocking manner.

I collected a CPU profile (see below) of the go process and I see that about 50% of CPU is spent in gRPC. Out of which, only about 20% is spent in I/O. I assume that the remaining 30% is spent in marshalling/unmarshalling the messages. Given that all the communications is going to be limited to just one node, is there any way that I could tune gRPC to get better performance? For example, is there a way to avoid the overhead in constructing HTTP2 messages? Essentially, what I'm looking for is a way to use gRPC for Inter Process Communication.

Thanks,

--Gautham

[Nicolas Noble]

We don't have that sort of optimization at the moment, no. Even if you use unix domain sockets, it still go through the whole process. 

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/4aa144cb-587b-4286-8832-cad1528ca12b%40googlegroups.com.

[Andrey Tcherepanov]

Any plans to look into that, or it is not of any importance?

On Tuesday, December 10, 2019 at 8:14:37 AM UTC-7, Nicolas Noble wrote:

We don't have that sort of optimization at the moment, no. Even if you use unix domain sockets, it still go through the whole process. 

On Mon, Dec 9, 2019 at 10:56 PM Gautham Banasandra <gautham....@gmail.com> wrote:

Hi all,

I'm using gRPC to communicate between a go and C++ process running on the same node. The C++ process hosts the gRPC server and the go process is the client. The go process makes a lot of gRPC calls hosted by the gRPC server in the C++ process in a blocking manner.

I collected a CPU profile (see below) of the go process and I see that about 50% of CPU is spent in gRPC. Out of which, only about 20% is spent in I/O. I assume that the remaining 30% is spent in marshalling/unmarshalling the messages. Given that all the communications is going to be limited to just one node, is there any way that I could tune gRPC to get better performance? For example, is there a way to avoid the overhead in constructing HTTP2 messages? Essentially, what I'm looking for is a way to use gRPC for Inter Process Communication.

Thanks,

--Gautham

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.

To unsubscribe from this group and stop receiving emails from it, send an email to grp...@googlegroups.com.

[Srini Polavarapu]

Currently there is no plan to do this and I don't think it has a lot of value. One option is to write your own interceptors on both sides to bypass HTTP/2 stack. You'll have to handle deadlines, flow control, multiplexing etc. on your own. Essentially, you'll be implementing your own transport between the two processes.