I’m guessing the publication needs to check each user’s mergebox that nothing has changed for them?
From my understanding of data-loading in the guide, changes are only sent to mergebox after they are noticed by the observer. In this case nothing on the db is actually changing (none of the tokens are old enough to be removed) so the observer shouldn’t notice anything, let alone send them to mergebox. But I admit that I know nothing about the internals of publications, observers or mergebox.
btw, I’m deploying using mup without using OPLOG.
I don’t know how the PollingObserverDriver works, but could the poll-and-diff algorithm be kicking in for all these user’s publications at the same time if it sees a query which might have changed their records?
I might try enabling oplog to see if that makes a difference.
I’ve since enabled oplog and it makes a huge difference. I redeployed at 16:03:
There is a small spike in total fetched documents and CPU every 10 minutes, coinciding with the token removal setInterval:
3 Likes
Yeah I’m not familiar with how everything works inside, but thought it might help.
Wow that’s a big difference! Good find!
Looks much better to me now, so it’s was the poll-and-diff algorithm that is causing this spike.