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

Broadcasting performance may be low #6

Closed
christophfriedrich opened this issue Aug 13, 2018 · 1 comment
Closed

Broadcasting performance may be low #6

christophfriedrich opened this issue Aug 13, 2018 · 1 comment

Comments

@christophfriedrich
Copy link
Contributor

If we keep the way subscriptions are currently stored (which is: per user and then per topic+parameter hash) it is necessary to loop through all users and check whether they subscribed to the topic+parameter in order to broadcast a message concerning that topic+parameter. This may be slow if there are many open connections.

If it was the other way round (i.e. having a Map of topic+parameter hash to a list of all subscribers) the need for this search would be eliminated.

On the other hand this would mean that we would have to loop through all topic+parameter settings to remove the user's subscriptions once the connection is closed.

So it's a trade-off between the two operations broadcast vs. close connection. I think the first case (broadcasting messages) will happen more often, so the subscriptions storage should be organised by topic+parameter to improve overall performance.

Thoughts?

@m-mohr
Copy link
Member

m-mohr commented Feb 13, 2020

Closing as subscriptions are not part of the API any longer.

@m-mohr m-mohr closed this as completed Feb 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants