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.
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?