Aggressive vs. Conservative gRPC Keepalive Settings for Idle Connection Pool Management

Goal: Keep the gRPC client connection pool from exhausting file descriptors or memory by preventing dead connections from lingering, while keeping keepalive‑induced overhead low enough to stay within middlebox idle‑timeout limits and avoid unnecessary CPU/network load.

Constraint: The exact idle timeout enforced by firewalls, sidecar proxies or cloud load balancers is rarely observable, and client library defaults differ (e.g., Go disables keepalive, Java uses 30 s/10 s). Choosing a keepalive_time that is too short generates frequent PING frames and may hit connection‑rate limits; choosing a value that is too long allows silent TCP drops, letting stale connections accumulate until the pool is exhausted.

Should the client enable keepalive_permit_without_calls to send pings on truly idle channels, or rely on application‑level traffic to keep paths open? Is a static conservative keepalive_time (e.g., 2 h) preferable to an adaptive scheme that adjusts based on observed RTT or recent connection failures? Which trade‑off—lower keepalive overhead versus faster dead‑connection detection—better aligns with typical deployment topologies where middlebox timeouts range from 60 s to 300 s?