Question about server performance... Are we doing something wrong?

[ericoe]

First let me thank you for this wonderful package!

We must be doing something wrong... There seems to be too much server activity for a single update... and really busy for several consecutive (though uncoupled) updates.

When we do a single update like this:

Cards.update(
	{_id: id},
	{$set: newData},
	{
		tx: true,
		context: {deckId: card.deckId, cardId: id}
	}
);

We get 4 invocations of tx.checkPermission. I can almost understand 3, but 4?
We also get 2 "Executed update" logs.

If we make several of these "single transacted updates" in a client-side loop... things get really strange. The first one generates 4 invocations, 2 executes... the second one 8 invocations and 4 executes, the third generates 12 and 6, etc. It is as if the tx processor thinks that the subsequent updates are somehow related to each other. (They are not.)

The Kadira logs for a single update look like this:

find/fetch card
find/fetch card
find/fetch transaction
update card
update card
find/fetch transaction
find/fetch oplog

Why 2 fetches on the card? Why 2 updates?
And, in the case where the client is doing several updates in a loop... the Kadira log is really nasty... following a similar pattern described in the 4/8/12/16 above.

I'd appreciate any suggestions or insight.
Thanks!
Eric

[JackAdams]

Yes, this is strange. These, as written, should auto-commit and just execute sequentially.

What exactly does a newData object look like? If it's actual data to overwrite the card's data in its entirety, it won't work -- the package doesn't support that kind of update. The newData object would have to be of the form:

{ set: { field1: value1, field2: value2 } }

[ericoe]

Yes. newData is exactly as you guessed.
If we track this down you'll be the first we tell.
Thank you.