Connection Reuse and HTTP/2 Multiplexing
gRPC's performance advantage over many REST setups starts with HTTP/2 multiplexing: a single TCP connection carries many concurrent RPC streams, avoiding the connection-per-request overhead and head-of-line blocking at the HTTP layer that plagued HTTP/1.1. However, this benefit disappears if client code naively creates a new channel per request instead of reusing a long-lived channel; channel creation involves a TCP handshake and, for TLS, a full handshake negotiation, so churning channels defeats the entire point of multiplexing and can dominate latency under load. Most gRPC client libraries also perform connection pooling and automatic reconnection internally, but only when the application holds onto and reuses a single channel object across calls.
Cricket analogy: Reusing a single gRPC channel is like a stadium keeping one broadcast feed running continuously through an entire Test match rather than re-establishing the satellite uplink before every over.
A common performance anti-pattern is instantiating a new gRPC channel (or client) for every RPC call inside a hot request path. This pays the TCP/TLS handshake cost repeatedly, defeats HTTP/2 multiplexing, and can add tens to hundreds of milliseconds of latency per call under load. Always create the channel once, at application startup or per logical peer, and reuse it for the lifetime of the process.
Message Size, Serialization, and Payload Design
Protocol Buffers' binary encoding is compact and fast to serialize compared to JSON, but message size still matters: very large single messages (multi-megabyte blobs, for instance) can dominate latency and memory usage, and by default gRPC enforces a 4MB max message size that must be explicitly raised via grpc.max_receive_message_length if larger payloads are genuinely needed. Rather than raising the limit, the better pattern for large payloads is usually to switch that particular RPC to server-streaming, chunking the data into a sequence of smaller messages so memory footprint stays bounded and the client can start processing before the full payload has arrived, improving perceived latency significantly.
Cricket analogy: Chunking a large payload into a stream is like a ground delivering ball-by-ball updates throughout an innings rather than one giant scorecard dump only after all 50 overs are bowled.
conn, err := grpc.Dial("reports.internal:443",
grpc.WithTransportCredentials(creds),
grpc.WithDefaultCallOptions(
grpc.MaxCallRecvMsgSize(16*1024*1024), // raise only if streaming isn't viable
),
)
// Preferred: stream large reports in bounded chunks instead of one giant message
func (s *reportServer) StreamReport(req *pb.ReportRequest, stream pb.ReportService_StreamReportServer) error {
for chunk := range generateChunks(req.ReportId, 64*1024) {
if err := stream.Send(&pb.ReportChunk{Data: chunk}); err != nil {
return err
}
}
return nil
}Choosing Between Unary and Streaming for Throughput
Unary RPCs are simplest but pay per-call overhead (context setup, potential connection-level flow-control window renegotiation) for every single request, so a workload that needs to send thousands of small items is often significantly faster as one client-streaming RPC than as thousands of individual unary calls, because it amortizes that overhead across the whole batch. Conversely, streaming introduces its own costs: HTTP/2 flow control windows must be sized appropriately (grpc.WithInitialWindowSize and grpc.WithInitialConnWindowSize in Go) or a fast producer can stall waiting for window credit from a slower consumer, and long-lived streams also complicate load balancer behavior since most L4/L7 balancers distribute at the connection level, not per-RPC, risking uneven load across backend replicas.
Cricket analogy: Batching many small updates into one client-streaming RPC is like a fielding captain sending one consolidated field-placement instruction to the whole team rather than radioing each fielder individually before every ball.
gRPC's default flow-control window (65535 bytes) is often too small for high-throughput streaming workloads and can bottleneck a fast producer talking to a slower or higher-latency consumer. Tuning grpc.WithInitialWindowSize (stream-level) and grpc.WithInitialConnWindowSize (connection-level) upward, alongside enabling keepalive settings, is a common production tuning step for latency-sensitive or bulk-streaming gRPC services.
- Reuse a single long-lived gRPC channel per peer; creating a channel per request defeats HTTP/2 multiplexing and adds handshake latency.
- Default max message size is 4MB; raising it should be a last resort compared to switching large payloads to server-streaming.
- Server-streaming large responses bounds memory usage and lets clients start processing before the full payload arrives.
- Batching many small operations into a single client-streaming RPC amortizes per-call overhead versus thousands of unary calls.
- HTTP/2 flow-control window sizes (grpc.WithInitialWindowSize/InitialConnWindowSize) must be tuned for high-throughput streaming.
- Long-lived streams complicate load balancing since most balancers distribute at the connection level, not per-RPC.
- Protobuf's binary encoding is more compact and faster to (de)serialize than JSON, but payload design still matters at scale.
Practice what you learned
1. Why does creating a new gRPC channel for every RPC call hurt performance?
2. What is gRPC's default maximum message size?
3. What is generally the preferred alternative to simply raising the max message size for a very large payload?
4. Why might batching thousands of small operations into a single client-streaming RPC outperform issuing thousands of individual unary RPCs?
5. What can happen if HTTP/2 flow-control windows are left at small default sizes for a high-throughput streaming RPC?
Was this page helpful?
You May Also Like
gRPC with Node.js or Go
How to build gRPC servers and clients using the official Node.js (@grpc/grpc-js) and Go (google.golang.org/grpc) libraries, and where their concurrency models diverge.
Testing gRPC Services
Strategies and tools for unit testing, integration testing, and manually exercising gRPC services, including grpcurl, in-process servers, and mocking generated clients.
gRPC Quick Reference
A condensed cheat sheet of gRPC RPC types, status codes, .proto syntax essentials, and CLI/tooling commands for fast lookup.
Related Reading
Related Study Notes in Web Development
Browse all study notesWebSockets Study Notes
Web Development · 30 topics
Web DevelopmentWebAssembly Study Notes
WebAssembly · 30 topics
Web DevelopmentSpring Boot Study Notes
Java · 30 topics
Web DevelopmentFlask Study Notes
Python · 30 topics
Web DevelopmentDjango Study Notes
Python · 30 topics
Web DevelopmentNext.js Study Notes
JavaScript · 30 topics