Performance best practices

Always re-use stubs and channels when possible, and use keepalive pings to keep HTTP/2 connections alive during periods of inactivity so initial RPCs start without delay — for example the C++ channel argument GRPC_ARG_KEEPALIVE_TIME_MS. Use streaming RPCs for a long-lived logical flow of data in either or both directions: streams avoid continuous RPC initiation, which includes client-side connection load balancing, starting a new HTTP/2 request at the transport layer, and invoking a user-defined method handler on the server. However, streams cannot be load balanced once started and can be hard to debug when they fail, and they may help at small scale while reducing scalability — use them only when they provide substantial benefit, to optimize the application rather than gRPC itself. Each connection also limits concurrent streams, and excess RPCs queue in the client; high-load applications can create a separate channel per area of high load or use a pool of channels with distinct channel args. Note the streaming guidance does not apply to Python, where streaming RPCs are much slower than unary. Scope: gRPC. Reviewed October 4, 2026.