I’m experimenting with large quantities of users (2500+) all connecting near simultaneously and needing the same data/query via a publication (e.g. think chatroom users getting a static chat history from the day before). I don’t want to use a Meteor Method because 2500+ shouldn’t all query Mongo for the same data.
So I want to leverage that fact that publications with an identical query observer will cache the result for additional clients in the future. I actually don’t even need reactivity, just a static data set (per my use case above). So I understand if I only implement the
added function of a publication then I’m solely adding documents and thus not processing
removed. I was also thinking on the client I could call
subscriptionHandle.stop() immediately after fetching the data (perhaps in the callback of the
subscribe(...)). I would call
subscriptionHandle.stop() just to further reduce server overhead after fetching my data. I’m banking on the idea of the server having the observer cached for the identical query that every client is doing (e.g.
My question is, if every client immediately calls a
stop() after fetching the data (because the data is static and “continued reactivity” is not needed nor will any new chats be added), will the server continue to have a cached observer/query for this publication and thus send the data from the cache and not hit Mongo?
I worry that if each client is immediately calling
stop() and the server doesn’t cache a publication observer for a set length of time, then each client (or at least a lot them) will not find a cached observer on the server and thus hit Mongo again. When the “last” client calls
stop() does the server then tear down the cached query/observer?
So I’m wondering what
subscriptionHandle.stop() actually does on the server in regards to caching.