Transactions are too slow, very slow

Just to be super-clear, I only see two ways reactivity is achieved in Meteor: oplog TAILING (OplogObserveDriver) and database polling (PollingObserveDriver). What is oplog “polling”?

The default database polling interval is 10 seconds (meteor/packages/mongo/polling_observe_driver.js at 7da5b32d7882b510df8aa2002f891fc4e1ae1126 · meteor/meteor · GitHub) so the average sync time should be 5 seconds, which is close to what I have experienced.

The oplog is not used if you use MUP and MONGO_OPLOG_URL is not set. On Galaxy, I suspect MONGO_OPLOG_URL should be set properly, so what the OP is experiencing might be related to the cases where observe fall backs to polling if it cannot implement oplog tailing for a particular cursor ($text queries, $natural sorting, etc.), see meteor/packages/mongo/mongo_driver.js at 7da5b32d7882b510df8aa2002f891fc4e1ae1126 · meteor/meteor · GitHub.

It’s the same. Tailing refers to cursor tailing which effectively means “get new entries from a cursor when they appear”. But the protocol is still pull-based, i.e., server has to ask the database for new entries (the database does not push new entries to the server), so I call it polling. Sorry for the misunderstanding!

I think this explanation is still vague.

The Oplog observe driver is mainly driven by oplog tailing, and falls backs to “polling” (i.e. executing the query corresponding to the cursor) or “fetching” individual documents episodically. It only does so at initialization, or when it does not know how to compute the current state of the cursor from the previous state and the next oplog entry.

The Polling observe driver on the other hand, exclusively relies on polling the query, and the default polling period seems to be 10 seconds.

So back to my question: I am speculating that either the OP did not configure MONGO_OPLOG_URL, or since the OP did not share exactly what query they use in the subscription that updates slowly after transactions, that their query cannot be handled by the OplogObserveDriver. In both cases, they should be observing an average delay of 5+ seconds between triggering the action and seeing the updated subscription.

I originally mistakenly assumed that they were deploying on Galaxy, which should rule out a misconfiguration of MONGO_OPLOG_URL. But rereading the thread I realize they meant they are using official MongoDB hosting, but they said nothing about official Meteor hosting.