http: select stable stream ID source based on route table #246
Conversation
This file contains 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
We've gone through a few different iterations of how we select the stable random ID uses for request routing. We used to use a random number for all requests, but this yields a performance hit when there is no need for a true random number. Then we switched to an incrementing ID which gives approximate randomness at high RPS, but is confusing for new users and in certain cases does not really provide the expected behavior. In this commit we implement both cases. If the route table does not use runtime we use the fast approach. If it uses runtime, we use a real random number which will provide behavior that most people would expect.
|
@lyft/network-team @rshriram |
|
Matt,
I don't know if Enrico reached out to describe the technique we frequently
use at Google to address the perf issues with PRNG for UID like issues?
- Louis
…On Tue, Nov 29, 2016 at 10:30 AM, Matt Klein ***@***.***> wrote:
@lyft/network-team <https://github.com/orgs/lyft/teams/network-team>
@rshriram <https://github.com/rshriram>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#246 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AIoKPHrWakQZk59tINOcJBbEUCaldOO8ks5rDG87gaJpZM4K_UOo>
.
|
|
@louiscryan no, he didn't. Any help/guidance appreciated on this. |
RomanDzhabarov
approved these changes
Nov 29, 2016
|
tldr;
we don't allocate one id at a time, we allocate a very large block of them
into a contiguous memory block all at once and then we slice out of that
over time. In a low thread count system its thread-local, in high thread
count systems the slicing is done under lock or by using atomics. All
fairly typical cost amortization stuff.
Using a faster PRNG to allocate the block also helps substantially. E.g.
http://www.pcg-random.org/download.html
…On Tue, Nov 29, 2016 at 10:39 AM, Matt Klein ***@***.***> wrote:
@louiscryan <https://github.com/louiscryan> no, he didn't. Any
help/guidance appreciated on this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#246 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AIoKPPZkjy28LlKlGoPvZFXTM6kNx75sks5rDHFjgaJpZM4K_UOo>
.
|
|
@louiscryan interesting. Thanks, makes sense. I will open a different issue to track improving how we do PRNG. |
Closed
duderino
referenced
this pull request
in duderino/envoy
Oct 12, 2019
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
PiotrSikora
pushed a commit
to PiotrSikora/envoy
that referenced
this pull request
Aug 2, 2020
* format fix Signed-off-by: Kuat Yessenov <kuat@google.com> * ecds: fix a flake in the integration test (envoyproxy#12268) Signed-off-by: Kuat Yessenov <kuat@google.com> * format fix Signed-off-by: Kuat Yessenov <kuat@google.com>
jpsim
pushed a commit
that referenced
this pull request
Nov 28, 2022
* build: Update bazel to 0.28.0 Signed-off-by: Keith Smiley <keithbsmiley@gmail.com> * Remove rules_foreign_cc override Signed-off-by: Keith Smiley <keithbsmiley@gmail.com> * Change depset to list Signed-off-by: Keith Smiley <keithbsmiley@gmail.com> * Update rules_apple Signed-off-by: Keith Smiley <keithbsmiley@gmail.com> * Update rules_apple to HEAD Signed-off-by: Keith Smiley <keithbsmiley@gmail.com> Signed-off-by: JP Simard <jp@jpsim.com>
jpsim
pushed a commit
that referenced
this pull request
Nov 29, 2022
* build: Update bazel to 0.28.0 Signed-off-by: Keith Smiley <keithbsmiley@gmail.com> * Remove rules_foreign_cc override Signed-off-by: Keith Smiley <keithbsmiley@gmail.com> * Change depset to list Signed-off-by: Keith Smiley <keithbsmiley@gmail.com> * Update rules_apple Signed-off-by: Keith Smiley <keithbsmiley@gmail.com> * Update rules_apple to HEAD Signed-off-by: Keith Smiley <keithbsmiley@gmail.com> Signed-off-by: JP Simard <jp@jpsim.com>
arminabf
pushed a commit
to arminabf/envoy
that referenced
this pull request
Jun 5, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
We've gone through a few different iterations of how we select the stable
random ID uses for request routing. We used to use a random number for all
requests, but this yields a performance hit when there is no need for a
true random number. Then we switched to an incrementing ID which gives
approximate randomness at high RPS, but is confusing for new users and in
certain cases does not really provide the expected behavior.
In this commit we implement both cases. If the route table does not use
runtime we use the fast approach. If it uses runtime, we use a real random
number which will provide behavior that most people would expect.