Identifying HTTP/2 Flow‑Control Bottlenecks in gRPC

When thousands of gRPC streams share a single connection, the HTTP/2 flow‑control window can be exhausted before the application payload is processed. The default per‑stream window is 64 KiB and the connection window is 1 MiB. If many streams compete, the sender must wait for WINDOW_UPDATE frames, adding round‑trip latency that may dominate the overall request‑response time.

The goal is to quantify the time spent waiting for WINDOW_UPDATE relative to actual payload handling, so we know whether flow‑control tuning or other optimisations will help. Constraints include memory usage per connection, interaction with keep‑alive and max‑message‑size settings, and the need to avoid out‑of‑memory errors when increasing the window.

Which metric should best capture the window‑exhaustion stalls? At what concurrency threshold does the default window become the limiting factor? Should we adjust the flow‑control window before enabling message compression or vice‑versa?