Hello All, I currently have a bi-di gRPC service dealing with request streams that often contain quite big messages (several MBs). Resources needed to process request messages are limited, so to avoid buffering of such big messages, the service uses manual flow-control and requests only as many messages as it can process at the given time without a need to wait for resources (if there's enough resources, messages from a single stream may be processed concurrently in separate threads).
Currently all clients of this service are in the same cluster, so network delays are negligible: request messages arrive almost instantly when requested, so the fraction of time when resources are idle is thus also negligible. However soon there will be client calls from different regions and later also calls from mobile clients. Am I assuming correctly, that the current flow-control strategy will result in much more wasted idle times of the processing resources? The service is implemented in Java in case it matters. As I understand, if both the delay and the average processing time are stable, the service could be requesting additional `networkDelay / averageMessageProcessingTime` messages each time. This condition however may not always be the case, especially for mobile clients. Do I understand correctly, that in order to optimize resource utilization, I would need to implement something similar to dynamic TCP window size negotiation (but for messages, not bytes) or is there maybe some built-in, ready to use mechanism already in place to deal with this? In case I need to deal with it myself, are there any APIs in the Java library that may be helpful? For example for measuring message network delivery delay of messages, number of request messages currently buffered by the server side that are awaiting processing, etc. Thanks! -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/553aa6c3-713f-438c-9839-58a8f8d245e7n%40googlegroups.com.
