You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@Half-Shot mentioned that upon start up, Synapse will send all missed ephemeral events to application services that have opted into receiving them (see MSC2409). There are some performance issues present with the feature's implementation in a couple of different circumstances.
Some background: a "stream token" is an incrementing integer. Every occurrence (a new typing event, a new read receipt, etc.) gets one of these IDs, and they're (usually rigidly) ordered in this way. Thus we can simply keep track of the last successfully sent stream token per app service to know what the AS needs to still receive.
When it comes time to send out the ephemeral events the appservice has missed, Synapse will send all read receipts and presence updates that it knows about and that are relevant to the namespaces the appservice has registered:
This historical data isn't very useful to the appservice as it has just been registered.
When a bridge has been offline for a while and comes back: it will receive all missed, relevant EDUs since it went offline. In particular, historical EDUs are typically less useful than the current state of things.
I'd be tempted to implement a time bound to the EDUs we send to appservices, such that very old EDUs are no longer considered.
Fixing both of these would help reduce the large amount of EDUs that can be sent to and overload both the appservice and Synapse itself when it tries to pull all of that information out of the database.
Finally, note that the above problems only seem to apply to the implementation of read receipts and presence events. Historical typing events are flat out not sent to appservices:
This issue has been migrated from #10836.
@Half-Shot mentioned that upon start up, Synapse will send all missed ephemeral events to application services that have opted into receiving them (see MSC2409). There are some performance issues present with the feature's implementation in a couple of different circumstances.
Some background: a "stream token" is an incrementing integer. Every occurrence (a new typing event, a new read receipt, etc.) gets one of these IDs, and they're (usually rigidly) ordered in this way. Thus we can simply keep track of the last successfully sent stream token per app service to know what the AS needs to still receive.
https://github.com/matrix-org/synapse/blob/bdfde6dca11a9468372b3c9b327ad3327cbdbe4a/synapse/storage/databases/main/appservice.py#L387-L412
When it comes time to send out the ephemeral events the appservice has missed, Synapse will send all read receipts and presence updates that it knows about and that are relevant to the namespaces the appservice has registered:
https://github.com/matrix-org/synapse/blob/a8a27b2b8bac2995c3edd20518680366eb543ac9/synapse/handlers/appservice.py#L266-L273
This historical data isn't very useful to the appservice as it has just been registered.
I'd be tempted to implement a time bound to the EDUs we send to appservices, such that very old EDUs are no longer considered.
Fixing both of these would help reduce the large amount of EDUs that can be sent to and overload both the appservice and Synapse itself when it tries to pull all of that information out of the database.
Finally, note that the above problems only seem to apply to the implementation of read receipts and presence events. Historical typing events are flat out not sent to appservices:
https://github.com/matrix-org/synapse/blob/a8a27b2b8bac2995c3edd20518680366eb543ac9/synapse/handlers/appservice.py#L235
The text was updated successfully, but these errors were encountered: