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.
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
Bust
_membership_stream_cache
cache when current state changes #17732Bust
_membership_stream_cache
cache when current state changes #17732Changes from 4 commits
2bd0e63
d327c62
64eb71f
dd87620
7c53716
bceb4e0
944d1e0
20ff239
f40e649
f5f0e36
7e328d7
ac06ddf
e52f5f0
bf695e6
2d20b71
484d045
6d29960
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Kinda weird to just stick this here (same with the others in
process_replication_rows
). Better way to organize this?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.
Separate from this PR and in line with the fact that these code paths need to be cleaned up, there is an obvious duplication here because we call
self._invalidate_caches_for_room_events(room_id)
insideself._invalidate_caches_for_room(room_id)
as well.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.
We don't actually insert anything into
current_state_delta_stream
during room deletion, so these are basically no-ops (as reading from the DB won't return anything new).Given how frequently rooms are deleted nowadays (as we delete rooms where everyone has left after N days, at least on matrix.org) I'm minded to remove these and leave a note. Otherwise I'm worried how this will affect perf
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.
Using the same logic, why do we call
self._invalidate_caches_for_room(room_id)
at all (just above)?Perhaps we consider the caches which only affect the
room_id
to be fine but we also have plenty that clear all of the keys in there (None
) which seem just as bad.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.
We do delete a lot of stuff when deleting a room (obviously), and so those caches do contain different data than what is in the DB. So invalidation makes sense in that case?
For the
current_state_delta_stream
nothing actually gets inserted and so the_curr_state_delta_stream_cache
cache wouldn't contain a different answer than what is in the DBThere 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.
So you're saying that we don't delete from
current_state_delta_stream
when deleting a room. And we don't use_curr_state_delta_stream_cache
for anything except when fetchingcurrent_state_delta_stream
so there is no need to bust the cache at the moment in this scenario.That looks correct:
synapse/synapse/storage/databases/main/purge_events.py
Lines 502 to 508 in 2d23250
But
_membership_stream_cache
is used forcurrent_state_delta_stream
androom_memberships
and we do purge fromroom_memberships
when deleting a room so it feels like we need to keep this one around.synapse/synapse/storage/databases/main/purge_events.py
Line 461 in 2d23250
Overall, it feels very brittle to comment out
_curr_state_delta_stream_cache
here because the guarantee we're assuming is bound to change in the future. I can update if you insist.And given we're only busting the
_curr_state_delta_stream_cache
for that specificroom_id
, it doesn't feel disruptive in that case.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.
The issue is that
self._membership_stream_cache.all_entities_changed(token)
will essentially clear that cache. Given we do now purge rooms frequently on matrix.org I worry it will have a noticeable impact on the cache hit ratio. Ideally we'd make it so that we didn't have to clear the entire cache, but that starts getting fiddly quickly. Hence trying to figure out if we really need to clear the cache.Note that the stream change caches effectively only cache the absence of changes, i.e. "nothing has changed between tokens X and Y and so don't query the database". Hence, I think, if we remove rows from the DB we don't need to clear the cache as at worst it will report that something has changed at token X, at which point it will query the DB and discover nothing is there?
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.
I've commented out
self._membership_stream_cache.all_entities_changed(token)
when we delete a room and added a comment with context on why we think this is safe.Since the
self._curr_state_delta_stream_cache.entity_has_changed(room_id, token)
call only invalidates the specific room being deleted, I've left be. I don't think it has the same overarching impact that theall_entities_changed
variants do.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.
Previous conversation: #17512 (comment)
I decided to define it in some way given we're using it for cache busting below and was curious if it is actually correct. Still not confident whether it's perfect for cache busting but might be good enough.
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 matches what we do for
_curr_state_delta_stream_cache
just above thisThere 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 the actual call that busts the the membership cache for the tests. I assume that is because this is what busts in monolith mode vs the other calls I've added are more for workers over replication