Publication / Subscription Performance

help
1

Hi!

I’m facing an issue regarding performance with publications / subscriptions. Here’s the scenario:
I have two collections, connectors and conversations.
Both are published like that — so with an identifier and some fields.

Meteor.publish('conversations', function(id) {
  return Conversations.find(
    { user: id },
    { limit: 1,
      fields: {
          user: 1,
          action: 1,
          messages: 1,
      } 
    }
  );
});

I’m subscribing on the client like that:

export default createContainer(() => {
		const messageHandle = Meteor.subscribe('conversation');
		const ready = messageHandle.ready();
		let userId = Meteor.userId();
    let conversation = Conversations.findOne({ user: userId }, { fields: { messages: 1, action: 1 } });
		let messages = conversation ? conversation.messages : false;
		let action = conversation ? conversation.action : false;
    return {
				messageHandle: messageHandle,
				ready: ready,
				messages: messages,
				action: action
    };
}, Messages)

When I log the arrival of a message:

incoming message Thu Oct 19 2017 16:53:20 GMT+0200 (CEST)
/* after the message was inserted into the db */
inserted message Thu Oct 19 2017 16:53:20 GMT+0200 (CEST)

But then, if you look at the client:

image
image1380×115 18.2 KB

Where could those 8 seconds of delay come from? Note that this is the case, even if I completely wipe out the database, so it is not an issue of huge data amounts.

What I’ve tried so far:

  • I added indices to the collections (should only matter for larger data though…)
if(Meteor.isServer) {
  Connectors._ensureIndex({ "identifier": 1, createdAt: -1 });
  Conversations._ensureIndex({ "user": 1, createdAt: -1 });
}
  • I added listener’s that stop subscriptions on the client, when the component unmounts, or the window is closed. Would also be interesting if this is necessary, or it is taken care of in the background?
this.props.messageHandle.stop();

Other than that, I’m really running out of ideas — any help is appreciated :slight_smile:

2

Are you using oplog or polling?

3

Well, first of all: thank you for asking the question. Indeed, I was suspecting, that there was some kind of polling going on in the background that is causing the delay, but I couldn’t find any real answers about this. With the info about oplog it makes sense of course.
Although, according to this article oplog tailing is activated by default in development. I’m facing the issue in development as well as production though.

4

nb. if { user: id }, is passed from the client, any user can pass in any id. You probably want Meteor.userId() or this.userId instead if these are bound to the user.

1 Like
5

Update: I have found the underlying error:
Unfortunately, I have updated the rawCollection instead of using the update function provided by Meteor. :man_facepalming: Of course then the client was not directly informed about the update.