-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
receive/store: use Client.String() #7406
base: main
Are you sure you want to change the base?
Conversation
Use Client.String() instead of allocating a new string each time. With 15-20k req/s I have noticed that a lot of time is spent on allocating a new string here. Signed-off-by: Giedrius Statkevičius <giedrius.statkevicius@vinted.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, it's been a thorn in my eye as well.
return &localClient{ | ||
StoreClient: c, | ||
store: store, | ||
desc: fmt.Sprintf( | ||
"LabelSets: %v MinTime: %d MaxTime: %d", | ||
labelpb.PromLabelSetsToString(labelpb.ZLabelSetsToPromLabelSets(store.LabelSet()...)), mint, maxt, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we have a way to avoid fmt.Sprintf
here. I see it performs poorly and show up in CPU profiles
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the alternatives?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isnt it mitigated by this PR anyhow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this PR together with caching matchers reduced CPU usage by 10% on every single receiver node in our case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Use Client.String() instead of allocating a new string each time. With 15-20k req/s I have noticed that a lot of time is spent on allocating a new string here.