I think a better way to think about this is to consider if too many users are connected to publications on a single server in general, and not if too many users are connected to the same publication. Performance degrades quickly when the server is watching for updates for too many clients. I could be wrong, but I don’t think there’s much of a difference between 1,000 clients -> 1 pub, vs 500 clients -> 1 pub and 500 to another pub; it’s still 1,000 clients for the server to check if an update is relevant specifically to each user subscribed.
Of course, the activity within a specific publication has some effect, which is what I think is the root of your question (is it constantly changing?), but in general, it’s best to ask yourself if this needs to be specifically reactive. Do all clients (that happened to be connected right at the time of the update) need to see those changes immediately?
My suggestion is as follows:
- Create a method to fetch the settings from the db. Call this method when a template loads and pass it to a helper, some reactive var/dict, or just cache it regularly - wherever it needs to go.
- Set a reasonable interval to refetch for new settings (every 15s? 30s? 2m?).
Meteor.setInterval(() => Meteor.call('method') , 60 * 1000);
If all users are supposed to get the entire update of the col (i.e. there’s no specificity around certain docs in a col for specific users, or even within a certain doc, etc.) then you’re really having the publication work on overload for no reason. On an update to the handle the publication is instructed to observe, it checks to see for which of the connected users the update is relevant and then publishes the update to each of those users. It sounds like in this case, the whole update is always relevant to every user, in which case you should just use a method on an interval so the mergebox logic isn’t running its hat off for nothing.
Also, consider if most clients are always connected or if they frequently exit/re-enter. If they’re not always connected, then you can have this method run on the router level or some high-level general template (or layout) on load. Maybe if they’re on and off frequently, you only ever need to do that once each time they return. If they’re usually connected for longer durations, then the interval -> method implementation is a good solution.
In short, you are probably better off not forcing the server to watch for changes for 1,000 individual clients, and instead having each active client call a method on a 1m interval.
Separately, I would take a look at redis-oplog. It’s worked wonders for us.