Hi tison, We also have an optimization for in-process scenarios in IOTDB, see [1].
We choose not to use a RaftClient, but to call RaftServer.submitClientRequest directly. submitClientRequest is the entry point for RaftClient requests.In this way we avoid serialization/deserialization and network connection overheads.It is more of a hack, and we loses some RaftClient features like retry / redirect. Hope it helps. Regards, William [1] https://github.com/apache/iotdb/blob/71c55e9abd35d4238b54bf232c17fb02e0ab66ca/consensus/src/main/java/org/apache/iotdb/consensus/ratis/RatisConsensus.java#L207 > 2022年11月2日 13:38，Tsz Wo Sze <[email protected]> 写道： > > Hi tison, > > Just checked > https://grpc.github.io/grpc-java/javadoc/io/grpc/inprocess/InProcessChannelBuilder.html > > <https://grpc.github.io/grpc-java/javadoc/io/grpc/inprocess/InProcessChannelBuilder.html> > , it is an ExperimentalApi. We may make it configurable so that users can > choose between NettyChannelBuilder or InProcessChannelBuilder. > > Tsz-Wo > > > On Wed, Nov 2, 2022 at 1:00 AM tison <[email protected] > <mailto:[email protected]>> wrote: > Hi, > > I read that we're now always using: > > NettyChannelBuilder channelBuilder = > NettyChannelBuilder.forTarget(target.getAddress()); > > to build the gRPC channel. However, if the ratis client runs in the same > process, is it possible that we try to build an InProcessChannel first so > that gain better performance? > > The motivation is that I'm considering exporting more ports for the ratis > server (process) when writing downstream projects. In this case, when I'm > talking to the ratis cluster (the replicated state machines), I need to use a > ratis client so ratis can handle the consensus part. If I always initialize a > Netty channel for every client, it looks like a significant performance > concern. > > Best, > tison.
