feat(approx-prefix): share pod block hashes across EPP replicas - #5
Open
Lucas-Fernandes-Martins wants to merge 2 commits into
Open
feat(approx-prefix): share pod block hashes across EPP replicas#5Lucas-Fernandes-Martins wants to merge 2 commits into
Lucas-Fernandes-Martins wants to merge 2 commits into
Conversation
An all-active EPP pool splits prefix affinity N ways. Each replica only indexes the requests it handled itself, so the same prefix routes to a different pod depending on which replica Envoy picked, and the pods duplicate each other's cache instead of specialising. Implement CrossReplicaContributor on the approx producer so each replica publishes its per-pod block hashes and reads back the union. Produce takes whichever match is longer -- local or peer -- so a peer's view can only promote pods the local index would score as cold, never demote one. Off by default behind syncCrossReplicaState. crossReplicaBlocksPerPod can cap how many MRU hashes each pod publishes; 0 (the default) publishes the whole LRU, which is up to LRUCapacityPerServer entries per pod per sync.
newCrossReplicaPublisher discovers contributors by walking the datalayer's extractor map, so implementing CrossReplicaContributor is not sufficient on its own: a plugin that never registers as an extractor is never asked for its state. The approx producer, unlike inflight-load, was not a Registrant, so CrossReplicaState() would have been dead code at runtime. Register as an EndpointExtractor when sync is enabled. Extract itself is a no-op -- pod removal is still handled by CleanUpInactivePods -- and registration is skipped when sync is off so the default path does not gain an endpoint-notification-source it has no use for.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
An all-active EPP pool splits prefix affinity N ways. Each replica only indexes the requests it handled itself, so the same prefix routes to a different pod depending on which replica Envoy picked, and the pods duplicate each other's cache instead of specialising.
Implement CrossReplicaContributor on the approx producer so each replica publishes its per-pod block hashes and reads back the union. Produce takes whichever match is longer -- local or peer -- so a peer's view can only promote pods the local index would score as cold, never demote one.
Off by default behind syncCrossReplicaState. crossReplicaBlocksPerPod can cap how many MRU hashes each pod publishes; 0 (the default) publishes the whole LRU, which is up to LRUCapacityPerServer entries per pod per sync.
What type of PR is this?
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Release note (write
NONEif no user-facing change):