-
Notifications
You must be signed in to change notification settings - Fork 161
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
Optimise notifier #17765
base: develop
Are you sure you want to change the base?
Optimise notifier #17765
Conversation
We can update the counter once outside of the loop.
Turns out doing `.copy_and_advance` can be expensive
|
||
# The last token for which we should wake up any streams that have a | ||
# token that comes before it. This gets updated every time we get poked. | ||
# We start it at the current token since if we get any streams | ||
# that have a token from before we have no idea whether they should be | ||
# woken up or not, so lets just wake them up. | ||
self.last_notified_token = current_token | ||
self.current_token = current_token |
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.
These two variables were always the same, so may as well remove one of them
sync_channel.await_result() | ||
self.assertEqual(200, sync_channel.code) | ||
next_batch = sync_channel.json_body["next_batch"] | ||
|
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 because we now replace the current token rather than copy_and_advance
. The test is still asserting the same observable behaviour really.
The notifier is quite inefficient when it has to wake up many user streams all at once
From a silly benchmark this takes the time to notify 1M user streams from ~30s to ~5s