Performance impact of updates on hidden fields

performance
1

Hello,

For the last few weeks I’ve read quite a lot about meteor. Now, I know fully how to use it, and more or less what it does in the backend. However, I still do not know the internals of meteor very well and that makes me uncertain about a couple of things, like this:

Let’s say I have some kind of ‘chatroom’ concept, described by documents like:
{
id: 1234,
name: “Room 1”,
participants: [user_id1,user_id2,…]
}

Now I do not want to send the list of participants over the wire, this is just for internal use. So I create a publication for the rooms with only the id and name fields.

So far so good. But of course, there are somewhere some RPC calls that adds or removes a user from this list of participants. And we assume there are a lot of users joining or leaving rooms, so this document will get updated a lot.

So a lot of stuff will get added to the mongodb oplog, but none of this should result in changes on the client side.
My question is what kind of load this puts on Meteor. Does meteor do something smart so it has to do almost no work in this scenario? Or does it have to calculate something for every subscribed client but it doesn’t send anything over the wire? Or will it still send the object to all users?

2

My two cents:

  1. Nothing will be sent to all users when updating ‘participants’ if you only publish ‘id’ and ‘name’.
  2. I believe adding data to an array is more costly than adding a doc to a collection. So depending on the queries you need in your app, you might consider removing the ‘participants’ field in Chatrooms and create a RoomParticipants collection like this:
    {
    id: 6666,
    userId: 1234
    roomId: 7777
    }
1 Like
3

I would find it very surprising if changing a field that’s not published to any client would result in any major work on the server.

If I would implement this, I would start with figuring out which fields being effected by the update operation, then loop through all the cursor that’s been published (in the same collection) to find those publishing fields that are effected by the update, and finally for those cursors figure out how they are effected by the update operation.

If Meteor uses a similar algorithm, each update would just loop through all the published cursors for that collection (and do nothing). If you have a hell lot of cursors, this could be a problem, but I think most client will share the same cursor in your case.