-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Audit device list updates #4115
Comments
I'm observing slow logins due to Synapse having to announce device updates over federation. matrix-corporal, having to manage settings for lots of users on a homeserver, frequently logs in with each user account, does some work and soon after logs out. It sends login requests like this: {"type": "m.login.password", "user": "..", "password": "..", "device_id": "Matrix-Corporal-Reconciler"} (Authentication always succeeds due to the use of the matrix-synapse-shared-secret-auth password provider. This, however, is irrelevant). Because this is a new For users in lots of big rooms, this triggers some log entry like this:
I'm guessing the actual federation transmission happens later (somewhat slowly), but still, one or all of these seems to take time:
As a result, a single matrix-corporal would then proceed to do some work with the access token. Once matrix-corporal is done (a second or two later), it would play nice and perform a Logging out appears to take around 1 second for such user accounts. It would be nice if:
I guess the above is bit of a special case. I'm not sure how many other automation projects need to log in and create such short-lived devices. Still, it would be great for everyone if all the scheduling + federation work happened asynchronously (even without the ability to cancel-it-out). Another thing that would help out my use case is if Alternatively, supporting device-less |
@erikjohnston how much of this do you still think is relevant? |
I think this can be closed now, we've done a bunch of work touching device list updates in the past couple of years and they don't seem to be causing too much issues recently. If we do find there are still problems then lets open new issues with more details |
We're spending quite a bit of CPU and DB time handling device list updates (both local and remote). We should look at whether things are working as expected or if there are some optimisations we can make.
_prune_old_outbound_device_pokes
takes a lot of CPU and DB timeThe text was updated successfully, but these errors were encountered: