Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Make the backfill linearizer lock smarter to not block as often #13619

Open
Tracked by #15182
MadLittleMods opened this issue Aug 24, 2022 · 0 comments
Open
Tracked by #15182

Make the backfill linearizer lock smarter to not block as often #13619

MadLittleMods opened this issue Aug 24, 2022 · 0 comments
Labels
A-Messages-Endpoint /messages client API endpoint (`RoomMessageListRestServlet`) (which also triggers /backfill) A-Performance Performance, both client-facing and admin-facing O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Minor Blocks non-critical functionality, workarounds exist. T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements.

Comments

@MadLittleMods
Copy link
Contributor

MadLittleMods commented Aug 24, 2022

Mentioned in internal doc about speeding up /messages. Also see "1. Backfill linearizer lock takes forever" in #13356


The linearizer lock on backfill is only used to de-duplicate work at the same time (it doesn't have anything to do with data integrity) (introduced in #10116). But the linearizer is very simplistic and we can make it smarter to not block so often.

Improvements

Block by ranges of depth per-room

Currently, the linearizer blocks per-room, so you're not able to backfill in two separate locations in a room.

We could update to have locks on ranges of depth for the room.

De-duplicate the same request/work

Currently, the linearizer has no de-duplication so if you send the same request 10 times in a row, they will all just rack up and do the same work over and over in sequence.

We could instead share the response from the first one to all the requests that are waiting.

The queue can build up above our timeout threshold

If we see that items in the queue are older than 180s, we should just cancel them because the underlying request to Synapse has timed out anyway. No need really to do work for a request that is no longer running.

Linearizer shared across all worker processes

Currently, the linearizer is per-process so if there are multiple client reader worker processes, we are potentially duplicating work across them. We do try to send traffic for a given room to the same worker though but there is no guarantee.

This is probably one of the optimizations to prioritize last.

@MadLittleMods MadLittleMods added the A-Messages-Endpoint /messages client API endpoint (`RoomMessageListRestServlet`) (which also triggers /backfill) label Aug 24, 2022
@DMRobertson DMRobertson added S-Minor Blocks non-critical functionality, workarounds exist. T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements. O-Uncommon Most users are unlikely to come across this or unexpected workflow A-Performance A-Performance Performance, both client-facing and admin-facing and removed A-Performance labels Aug 25, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-Messages-Endpoint /messages client API endpoint (`RoomMessageListRestServlet`) (which also triggers /backfill) A-Performance Performance, both client-facing and admin-facing O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Minor Blocks non-critical functionality, workarounds exist. T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements.
Projects
None yet
Development

No branches or pull requests

2 participants