Skip to content
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

[v11] Improve performance of ListResources #23597

Merged
merged 1 commit into from Mar 28, 2023

Conversation

rosstimothy
Copy link
Contributor

Backport #23534 to branch/v11

* Add benchmark for ListNodes

* Move RBAC logging to trace level

BenchmarkListNodes is twice as slow when RBAC logging is enabled.
By switching RBAC logging from debug to trace we can eliminate
the performance hit while still providing a way for users to opt
in to the behavior if they need to debug RBAC.

* Intern compiled regular expressions

Profiles of the benchmark test revealed that the `regexp.Compile`
done within `utils.matchString` was the most cpu and memory intensive
portion of the tests. By leveraging a `lru.Cache` to intern the
compiled regular expressions we get quite a performance improvement.

* Only fetch a single page of resources

Increases the request limit prior to loading the resources from
the cache so that we load enough items in a single page to determine
the start key of the next page.

* Remove version checking from `services.UnmarshalServer`

Unmarshal directly to a `types.ServerV2` instead of first creating
a `types.ResourceHeader` to inspect the version. There is only a
single version for `types.ServerV2` making the check unnecessary.

* Add `GetLabel` to `types.ResourceWithLables`

`GetAllLabels` can be overkill if one simply needs to look up the
value for a particular label. It creates a new `map[string]string`
and copies all of a resources existing labels. RBAC decisions
driven by labels incurred the penalty of the copy each time access
was checked. The impact of the copy is much more noticeable when
a resource has several labels or really long strings in the key
or value.

By leveraging `GetLabel` RBAC can avoid copying the labels altogether
and simply lookup each label key when required.
@rosstimothy rosstimothy marked this pull request as ready for review March 27, 2023 12:51
@rosstimothy rosstimothy added this pull request to the merge queue Mar 28, 2023
Merged via the queue into branch/v11 with commit deb92d2 Mar 28, 2023
17 checks passed
@rosstimothy rosstimothy deleted the tross/backport-23534/v11 branch March 28, 2023 18:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants