Repository navigation
fix(l7): track up to 1000 HTTP/2 streams per connection - #368
Merged
Merged
Conversation
gRPC clients multiplex long-polls over one connection by the hundred. A long-poll gets no response headers until it returns, up to a minute later. At the 100-stream limit those live polls were evicted, oldest waiting first, and their results lost. On a test cluster one node with long-polling workers evicted ~350 streams a minute. Locally, 300 concurrent 5-second requests on one connection completed 800-1,110 of 3,600. The limit is now 1000. Streams whose response was lost are still reclaimed by the stream GC, and a full table is ~200 KB.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request increases the maxActiveRequests limit for tracked concurrent HTTP/2 streams per connection from 100 to 1000 in ebpftracer/l7/http2.go. This change accommodates gRPC clients multiplexing many long-polls over a single connection, preventing legitimate live polls from being prematurely evicted. There are no review comments, and I have no additional feedback to provide.
RamanKharchee
approved these changes
Oct 6, 2026
blue4209211
approved these changes
Oct 6, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The HTTP/2 parser tracked at most 100 streams per connection. gRPC clients multiplex long-polls over one connection by the hundred, and a long-poll gets no response headers until it returns, up to a minute later. At the limit those live polls were evicted (#365 evicts requests still waiting for headers first) and their results lost.
On a test cluster, one node with long-polling workers evicted ~350 streams a minute and completed fewer than a third of the streams it created.
The limit is now 1000. Streams whose response was lost are still reclaimed by the stream GC (2 minutes), and a full table is ~200 KB per connection.
Engineering detail
Local e2e: built the agent from this branch and from main and ran each in a local Docker VM (kernel 6.10). A Go HTTP/2 client made 300 concurrent requests to a handler that answers after 5s (long-poll shaped), 60s per run, two runs each, 3,600 requests per run. Main: 1,110 and 800 completed, 2,490 and 2,800 evicted. This branch: 3,600 and 3,600 completed, 0 evicted. The
ebpftracer/l7tests pass.