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
[low priority] [idea] Match() cache. #33580
[low priority] [idea] Match() cache. #33580
Conversation
note this is largely untested, will verify it some more later. |
9c8b545
to
fadf5d0
Compare
Jenkins GCI GKE smoke e2e failed for commit fadf5d0. Full PR test history. The magic incantation to run this job again is |
@@ -28,6 +28,8 @@ type Labels interface { | |||
|
|||
// Get returns the value for the provided label. | |||
Get(label string) (value string) | |||
|
|||
String() string |
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.
this is a convenience interface update, that allows lookups in Match cache so that any Labels
support hashing. should generally work since there is a String rep, but havent tested it under all conditions
mutex env var for benchmarking
fadf5d0
to
ce499ed
Compare
Jenkins unit/integration failed for commit ce499ed. Full PR test history. The magic incantation to run this job again is |
Jenkins verification failed for commit ce499ed. Full PR test history. The magic incantation to run this job again is |
Jenkins GCI GCE e2e failed for commit ce499ed. Full PR test history. The magic incantation to run this job again is |
Jenkins GKE smoke e2e failed for commit ce499ed. Full PR test history. The magic incantation to run this job again is |
I think for now this is a microoptimization: the |
Problem:
Match
is using alot of CPU in issues like #31795 .Solution:
Disclaimer: I havent investigated wether or not redundant calls to match are happening, but i suspect if you had 1000 nodes, and say 100 pods per node, and were scanning labels, you could have alot of string comparison churn if the pods were identical or similar. I'd need to watch the match ops @ scale to really confirm if theres any redundancy.
Anyway, Here's a possibility for optimizing
Match()
performance. Could be improved via xref #33572 . I'll write some tests to confirm its cache speeds things up (At least in the obvious case scenarios). The hard part will be determining in the "real world" wether or not we have a high likliehood of bursts of identicalMatch
operations. cc @kubernetes/sig-schedulingThis change is