I’m attempting to publish the .count() of a cursor (which, as filtered, could have 100k-1mm large documents) in order to make a paginated view. I’ve been seeing ridiculous slowdowns (like 5+ seconds on page load) and 100% server CPU spikes when calling observeChanges() on this cursor; specifically, the spike is during the synchronous call to observeChanges() itself, not during any callbacks registered therein!
My hypothesis is that observeChanges is, at the time when it’s called, trying to get the ID of every single document that matches the selector, in order to be able to later determine if a deletion in the oplog applies to the selector. That iteration is very costly since it happens on every client load/refresh. I’d much rather have the server tail the oplog, and on any change to the collection, rerun .count() (which is fast if indexed) and notify me. Is there a recommended Meteor-specific way to do this, or should I try to dive into OplogObserveDriver-level stuff?