Skip to content

Conversation

@dhartunian
Copy link
Collaborator

On large clusters requesting all ranges just to compute the problem range data is wasteful and can take a very long time to do. This change introduces a new RPC endpoint which is more limited in scope and can be used by the existing problem ranges RPC to fetch just what's needed from all the nodes.

The new endpoint ProblemRangesLocal only retrieves the problem range counters for the local node eliminating the need to fetch all and filter at the gateway.

Epic: None
Resolves: #121706

Release note: None


Note for reviewers:

This is an LLM generated diff. There's some cruft that I want to clean up in the tests. They have unnecessary comments and can perhaps be combined into a single test with a bunch of cases. Mostly looking for feedback on whether this approach is a reasonable solution to the performance bottleneck on large clusters. I'll do a closer pass if this is a good idea.


On large clusters requesting all ranges just to compute the problem
range data is wasteful and can take a very long time to do. This
change introduces a new RPC endpoint which is more limited in scope
and can be used by the existing problem ranges RPC to fetch just
what's needed from all the nodes.

The new endpoint ProblemRangesLocal only retrieves the problem range
counters for the local node eliminating the need to fetch all and
filter at the gateway.


Epic: None
Resolves: cockroachdb#121706

Release note: None
@dhartunian dhartunian requested review from a team as code owners December 5, 2025 21:00
@dhartunian dhartunian requested review from kyle-a-wong and removed request for a team December 5, 2025 21:00
@cockroach-teamcity
Copy link
Member

This change is Reviewable

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

o11y: problem ranges page doesn't load with large number of ranges

2 participants