Google's HTTP/2 codec slows Envoy
Engineers investigated a significant CPU performance regression in the Envoy proxy after switching from the nghttp2 codec to Google's oghttp2. The analysis confirms that the new codec is less efficient for header-heavy traffic and provides insights into benchmarking methodologies for network proxies.
Why it matters
Performance regressions in core infrastructure software like Envoy can significantly increase operational costs and latency for large-scale cloud deployments.
A while back we rolled a routine Envoy upgrade to one of our customers' dedicated proxies. Same config, same traffic, and the CPU graphs stepped up by roughly a fifth. This is the kind of chart that earns you a calendar invite with no agenda, so we decided to get ahead of it and started digging in.
Bisecting versions pointed at Envoy v1.34, which is where Envoy switched its default HTTP/2 codec from nghttp2 to Google's oghttp2. We weren't the first to notice: users had been reporting 15–25% latency regressions since that release, and v1.37.0 eventually flipped the default back , with a comment in the source promising to try again "once performance aligns with nghttp2." That fixed our customer. It did not fix our curiosity. Why doesn't it align? What does an HTTP/2 codec even spend its time on?
Get smarter about the news
Sign up free for a feed built around what you actually care about, Dive Deeper research on any story, and the full text of every article.
Create free accountAlready have an account? Sign in