--- title: gRPC-Go performance Improvements | daily.dev description: gRPC-Go maintainers detail flow control and performance work including expanding stream windows for large messages, decoupling connection-level flow control... canonical: https://daily.dev/posts/grpc-go-performance-improvements-bsbvkhfga twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: gRPC-Go performance Improvements | daily.dev og:description: gRPC-Go maintainers detail flow control and performance work including expanding stream windows for large messages, decoupling connection-level flow control... og:url: https://daily.dev/posts/grpc-go-performance-improvements-bsbvkhfga og:image: https://api.daily.dev/og/posts/BsBVkHfga.png og:image:alt: gRPC-Go performance Improvements og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # gRPC-Go performance Improvements **[gRPC Blog](https://daily.dev/sources/grpc-blog)** · 9 min read · 0 upvotes · 0 comments ## Summary gRPC-Go maintainers detail flow control and performance work including expanding stream windows for large messages, decoupling connection-level flow control from application reads, piggybacking window updates onto existing flushes, and BDP (Bandwidth Delay Product) estimation for dynamic window sizing. These changes yielded up to a 10x improvement for large messages on high-latency networks and closed the gap with HTTP/1.1 performance. Planned future work covers reducing flush syscalls and reducing memory allocations via buffer pooling. Benchmark tables compare gRPC against HTTP/1.1 and HTTP/2.0 across real and simulated networks with varying RTT and payload sizes. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is BDP (Bandwidth Delay Product) estimation in gRPC-Go and how does it improve performance? BDP estimation is a gRPC-Go feature that dynamically adjusts flow control window sizes based on measured network bandwidth and round-trip time. A receiver sends a BDP ping on receiving a data frame, counts bytes received over roughly 1.5 RTTs, and doubles the window size if the sampled bandwidth exceeds the previous maximum, up to a 4MB cap matching typical TCP flow control limits. It is enabled by default and closed the performance gap with HTTP/1.1 on high-latency networks. _daily.dev surfaces deep dives like this for teams tuning gRPC performance on high-latency links._ ### How much faster is gRPC-Go after expanding the stream window for large messages? Expanding the stream window when an application is actively reading a large message gave a 10x performance improvement on high-latency networks. Instead of receiving large payloads in chunks and issuing window updates as the window runs low, gRPC-Go proactively requests the whole message once it knows the application is committed to reading and has allocated memory for it, a technique originally used in gRPC-C. _Engineers optimizing RPC throughput can find this kind of benchmark data on daily.dev._ ### Why does gRPC-Go decouple connection-level flow control from application reads? Connection-level flow control in gRPC-Go was decoupled from application reads because a single slow or inactive stream sharing a connection could stall window updates for all other streams on that connection, hampering overall performance. Stream-level flow control still depends on application reads, but the connection-level window is instead capped near the network's Bandwidth Delay Product to bound throughput without letting one slow stream block others. _daily.dev helps developers track this kind of gRPC internals discussion when debugging multiplexed RPC performance._ ## Similar posts on daily.dev - [gRPC deep dive: from service definition to wire format](https://daily.dev/posts/grpc-deep-dive-from-service-definition-to-wire-format-mykdq3gjn) · Hacker News · 0 upvotes · 0 comments - [How Go’s Goroutines Power High-Performance API Gateways](https://daily.dev/posts/how-go-s-goroutines-power-high-performance-api-gateways-yepugd2cw) · Medium · 10 upvotes · 0 comments - [From RPC to gRPC: Understanding Remote Procedure Calls, Protocol Buffers, and Modern Distributed Systems Communication](https://daily.dev/posts/from-rpc-to-grpc-understanding-remote-procedure-calls-protocol-buffers-and-modern-distributed-sys-hdfydjpc0) · freeCodeCamp · 1 upvotes · 0 comments - [gRPC vs REST Is the Wrong Question · Buf](https://daily.dev/posts/grpc-vs-rest-is-the-wrong-question-buf-xe2qehlxz) · Buf Blog · 109 upvotes · 4 comments --- Tags: [#performance](https://daily.dev/tags/performance), [#golang](https://daily.dev/tags/golang), [#grpc](https://daily.dev/tags/grpc) [View this post on daily.dev](https://daily.dev/posts/grpc-go-performance-improvements-bsbvkhfga) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"gRPC-Go performance Improvements","url":"https://daily.dev/posts/grpc-go-performance-improvements-bsbvkhfga","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/grpc-go-performance-improvements-bsbvkhfga"},"datePublished":"2026-08-23T07:20:25.889Z","dateModified":"2026-08-23T07:23:36.716Z","description":"gRPC-Go maintainers detail flow control and performance work including expanding stream windows for large messages, decoupling connection-level flow control...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/10aae04dfd3ba4523d83e4087201877a?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/10aae04dfd3ba4523d83e4087201877a?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"gRPC Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"gRPC Blog","logo":"https://media.daily.dev/image/upload/s--asedGCAx--/f_auto,q_auto/v1787469607/logos/grpc-blog?_a=BAMAMicg0","url":"https://daily.dev/sources/grpc-blog"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/grpc-go-performance-improvements-bsbvkhfga","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"performance,golang,grpc","timeRequired":"PT9M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"gRPC Blog","item":"https://daily.dev/sources/grpc-blog"},{"@type":"ListItem","position":3,"name":"gRPC-Go performance Improvements"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/grpc-go-performance-improvements-bsbvkhfga#faq","mainEntity":[{"@type":"Question","name":"What is BDP (Bandwidth Delay Product) estimation in gRPC-Go and how does it improve performance?","acceptedAnswer":{"@type":"Answer","text":"BDP estimation is a gRPC-Go feature that dynamically adjusts flow control window sizes based on measured network bandwidth and round-trip time. A receiver sends a BDP ping on receiving a data frame, counts bytes received over roughly 1.5 RTTs, and doubles the window size if the sampled bandwidth exceeds the previous maximum, up to a 4MB cap matching typical TCP flow control limits. It is enabled by default and closed the performance gap with HTTP/1.1 on high-latency networks. daily.dev surfaces deep dives like this for teams tuning gRPC performance on high-latency links."}},{"@type":"Question","name":"How much faster is gRPC-Go after expanding the stream window for large messages?","acceptedAnswer":{"@type":"Answer","text":"Expanding the stream window when an application is actively reading a large message gave a 10x performance improvement on high-latency networks. Instead of receiving large payloads in chunks and issuing window updates as the window runs low, gRPC-Go proactively requests the whole message once it knows the application is committed to reading and has allocated memory for it, a technique originally used in gRPC-C. Engineers optimizing RPC throughput can find this kind of benchmark data on daily.dev."}},{"@type":"Question","name":"Why does gRPC-Go decouple connection-level flow control from application reads?","acceptedAnswer":{"@type":"Answer","text":"Connection-level flow control in gRPC-Go was decoupled from application reads because a single slow or inactive stream sharing a connection could stall window updates for all other streams on that connection, hampering overall performance. Stream-level flow control still depends on application reads, but the connection-level window is instead capped near the network's Bandwidth Delay Product to bound throughput without letting one slow stream block others. daily.dev helps developers track this kind of gRPC internals discussion when debugging multiplexed RPC performance."}}]} ```