Closed enforser closed 6 months ago
I haven't really dug into what would be required/is easily doable, but instead of adding such a low level api, I wonder if we could have an eager connect client setting. Or do you think it would be important to also be able to imperatively query-trigger connect later during the lifecycle of a client?
Eager connect sounds great and would suit my use case perfectly. In fact I think it would be fairly straightforward to add that.
It would just be calling .getState(true)
on the ManagedChannel
returned here: https://github.com/akka/akka-grpc/blob/main/runtime/src/main/scala/akka/grpc/internal/NettyClientUtils.scala#L112-L126
I've noticed that there is a significant delay on the first request of a newly instantiated client, which is caused by the extra time it takes to create the ManagedChannel for the client, and then to establish a connection with the server.
There exists a solution to this in other GRPC libraries where the channel state is exposed, and a method to eagerly transition to a connected state is provided.
With this functionality a user of akka-grpc could establish a connection early without making an actual RPC request to the server.
The effect of the connection creation overhead in a multi service architecture can lead to high delays that are not acceptable in low latency environments. Anecdotally, I am working with a system which makes 4 GRPC calls between four different services all synchronously (a -> b -> c -> d -> e). If I exclude the requests which occur on the first call from the client, the average time is far less than a second. On the first request though we consistently see 3-4s latencies.