Skip to content
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

Quality of Service #1280

Open
kegsay opened this issue Aug 18, 2020 · 1 comment
Open

Quality of Service #1280

kegsay opened this issue Aug 18, 2020 · 1 comment
Labels
long term An issue/feature which we would like to have at some point in the distant future T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements. X-Performance Issue/PR around something that is slow or taking lots of memory

Comments

@kegsay
Copy link
Member

kegsay commented Aug 18, 2020

  • A single user should not be able to degrade the performance of the server to such a point as to make other users unusable or unstable.
  • A single room should not be able to degrade the performance of the server to such a point as to make other rooms unusable or unstable.
  • Under extreme load, we should gracefully degrade non-critical traffic (typing, presence, receipts) over critical traffic (messages, device keys).
  • It should be possible to make exceptions for rooms and/or users to increase their usage quotas.

I'd like to at the least add basic support or think about how we would sooner rather than later as it's always bugged me that Synapse doesn't have this, which can result in a few malicious/buggy users crippling the server.

@kegsay kegsay added feature-req long term An issue/feature which we would like to have at some point in the distant future labels Aug 18, 2020
@kegsay
Copy link
Member Author

kegsay commented Aug 26, 2020

So for users this is easyish, just tarpit the user's requests (aka rate limit). For rooms, a similar tarpit would work, and likewise we could do the same for inbound federation.

As for graceful degradation, we need to know:

  • When to degrade
  • How to degrade

which implies we introspect our CPU/memory usage in accordance to some kind of limit, similar to how Android has onLowMemory() hooks. This would be per-component as they may be on different machines. Each component would handle the callback different, opting to drop typing/presence/receipts for example, and preserving messages/state sending.

@kegsay kegsay added X-Performance Issue/PR around something that is slow or taking lots of memory T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements. and removed feature request labels Dec 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
long term An issue/feature which we would like to have at some point in the distant future T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements. X-Performance Issue/PR around something that is slow or taking lots of memory
Projects
None yet
Development

No branches or pull requests

1 participant