-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Channel State API #1930
Comments
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 |
Will casue the client creation to trigger connection to server rather than first on initial request, can help avoiding latency for the first requests caused by waiting for connection to complete.
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.
The text was updated successfully, but these errors were encountered: