Yes, gRPC calls this feature the BDP probe (bandwidth-delay product) There's a short description of flow control here: https://grpc.io/docs/guides/flow-control/
It's somewhat old, but a gRPC dev suggests there's no way to influence this directly (other than by turning it off!): https://stackoverflow.com/questions/64050027/how-to-configure-grpc-http-2-flow-control-in-python On Fri, Jul 7, 2023, at 11:56, Wenbo Hu wrote: > Sorry, my bad. It works over time. > It seems that the grpc starts with a default window size, then update > to a stable value according to options. > > Wenbo Hu <huwenbo1...@gmail.com> 于2023年7月7日周五 23:32写道： >> >> Both my server and client are implemented in python now, Java Client >> may be in the future. >> Back pressure works, but not totally in control. >> Is there a way to configure how much memory used to read ahead for >> each grpc stream? >> For example, the client is calling do_get, then the client wants to >> limit the memory of FlightStreamReader, since the downstream >> processing is a time/memory consuming task. For its best option only >> read one record batch ahead with specified batch_size so that the >> minimum memory is used for streaming. >> Is "GRPC_ARG_HTTP2_STREAM_LOOKAHEAD_BYTES" used for that purpose? >> `generic_options=[("grpc.http2.lookahead_bytes", 100000)]` >> It seems not to take effect. I wrote a server sending the same record >> batch continuously 100 times, the client takes 1 sec to process each >> record batch read from do_get, no matter what value set, the server >> blocks at writing 14th/25th record batch... >> >> David Li <lidav...@apache.org> 于2023年7月7日周五 22:26写道： >> > >> > gRPC has backpressure built in. Is your server in Java or Python/C++? >> > >> > If in Java, the server needs to explicitly poll isReady to respect >> > backpressure. (This is rather wasteful, yes, and this will artificially >> > throttle your peak bandwidth because of a long-standing flaw in gRPC-Java.) >> > >> > If in Python/C++, the backpressure should be automatic (write calls will >> > block), so the client should just make sure not to read from the reader >> > until it actually wants data (there are lower-level options to tweak this, >> > IIRC) >> > >> > On Thu, Jul 6, 2023, at 23:18, Wenbo Hu wrote: >> > > Hi, >> > > I'm using arrow flight to transfer data in distributed system, but >> > > the lightning speed makes both client and server faces out of memory >> > > issue. >> > > For do_put and do_exchange method, the protocol provides stream >> > > metadata reader/writer for client/server exchange control messages >> > > along data stream. >> > > But do_get only returns a FlightDataStream without any extra >> > > control message can be used to communicate with each other. >> > > Also, the returned FlightDataStream is unaware of client >> > > canceling, while java has a cancel callback. >> > > My solution is to use do_exchange to replace do_get for client >> > > download data, or is there any better way to implement that? >> > > >> > > -- >> > > --------------------- >> > > Best Regards, >> > > Wenbo Hu, >> >> >> >> -- >> --------------------- >> Best Regards, >> Wenbo Hu, > > > > -- > --------------------- > Best Regards, > Wenbo Hu,
