Skip to content

balancer/weightedroundrobin: Add emissions of metrics through metrics registry #7439

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jul 26, 2024

Conversation

zasweq
Copy link
Contributor

@zasweq zasweq commented Jul 25, 2024

This PR adds emissions of weighted round robin metrics defined in A78.

RELEASE NOTES: N/A

@zasweq zasweq requested a review from dfawley July 25, 2024 20:53
Copy link

codecov bot commented Jul 25, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.49%. Comparing base (84a4ef1) to head (cad7458).
Report is 1 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #7439      +/-   ##
==========================================
+ Coverage   81.39%   81.49%   +0.10%     
==========================================
  Files         354      354              
  Lines       27053    27076      +23     
==========================================
+ Hits        22020    22066      +46     
+ Misses       3828     3814      -14     
+ Partials     1205     1196       -9     
Files Coverage Δ
balancer/weightedroundrobin/balancer.go 80.22% <100.00%> (+1.33%) ⬆️
balancer/weightedroundrobin/scheduler.go 100.00% <100.00%> (ø)
balancer/weightedtarget/weightedtarget.go 91.30% <100.00%> (+0.39%) ⬆️

... and 14 files with indirect coverage changes

@zasweq zasweq added the Type: Feature New features or improvements in behavior label Jul 25, 2024
@zasweq zasweq added this to the 1.66 Release milestone Jul 25, 2024
Comment on lines 397 to 398
// These fields are built out at creation time and read only after, so no
// need for synchronization.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// The following fields are immutable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure this is how I see it documented throughout the codebase in other places but it's equivalent to yours so switched for all three structs I added this comment for.

w.nonEmptySince = time.Time{}
return 0
return
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please (almost?) never use bare returns from functions that return values. It's too hard to read. Use return weight or, even better, keep as return 0.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll return weight so reader doesn't need to keep track of two pieces of information (named return value which gets logged and the actual return value).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO this is worse because now you have to go backtrack and figure out what weight might be while reading the code. If it just says return 0 then it's obvious.

Note that named return values are set upon returning. I.e.

func f() (x int) {
	x = 5
	defer func() {
		fmt.Println(x)
	}()

	return 10
}

Will print 10.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah ok I didn't realize named return values were set upon returning. Switched to incorporate all your suggestions.

@zasweq
Copy link
Contributor Author

zasweq commented Jul 26, 2024

Thanks for the pass :)! Got to all comments!

weight = 0
if forScheduler {
defer endpointWeightsHandle.Record(w.metricsRecorder, weight, []string{w.target, w.locality}...)
weight := float64(0)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Named return values are totally fine if you want to keep it. Just don't do a bare return, since it can be confusing (for a minute I actually thought you removed the return value when I saw the bare return, and had to go back to see what was happening).

(But you don't need to initialize them to 0 as in the previous code; Go always initializes everything to zero.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Switched to named return value.

}

return w.weightVal
weight = w.weightVal
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah...I'd prefer to use what you had before. Use the named return value, and don't ever assign to weight at all. Just read it in the defer to find out what was returned.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Switched to named return value.

@dfawley dfawley assigned zasweq and unassigned dfawley Jul 26, 2024
@zasweq zasweq merged commit 3eb0145 into grpc:master Jul 26, 2024
13 checks passed
printchard pushed a commit to printchard/grpc-go that referenced this pull request Jul 30, 2024
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 23, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Type: Feature New features or improvements in behavior
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants