still trying to understand Meteor internals after long experience with traditional web architectures, so apologize if my questions looks stupid.
I found that when I try to update particular Collection (in my example Users) document on client it is very slow.
Example:
// On client
Meteor.users.update({_id: "6ZPK9tQQd9FCtPoPP"}, {$set: {'profiles.test.interests.y7HagTm83PkEiExKv.experience': true}});
// Method call takes 3.300 to 0.002 (sometimes, cached???) seconds to execute
// Directly in DB same query
db.users.update({_id: "6ZPK9tQQd9FCtPoPP"}, {$set: {'profiles.test.interests.y7HagTm83PkEiExKv.experience': true}})
// It is always 0.001-0.002 seconds
In WebSocket log, I see that update message appears there with the same lag, so I assume, that something is happening BEFORE the actual call to server.
What can be the cause of such huge lags on the client, and how to resolve that?
It’s difficult to tell without seeing your code, but one thing you should consider doing is wiring your app with Kadira (they have a free version). It will tell you exactly what’s happening and make troubleshooting much easier. Other than that if you can share some version of your code showing the issue, we can take a look.
Actually there are lots of code around it, as it’s quite big application. So I don’t know what can relate to this update query. That’s what I’m trying to understand - where to start digging, if such lag is not a norm
Since the client is slow it would actually probably more helpful to do use the browser’s profiler. If you have a lot of active queries on the users collection that could make the update slow (that particular problem will actually be fixed in 1.3).
Checked with the the Kadira debugger. It shows in chart that Blaze executions takes long time.
It seems that update is blocking by nested Blaze templates. So I’ve optimized templates and reduced time for update around 3 times (to 0.7-1 sec).
On the other hand this delay is still long, so I’ll try to find solution how to disable reactivity for some templates or make them non-blocking using Optimistic UI.
While I cannot find any mention of how it works in API docs (http://docs.meteor.com/) … There is only a mention of Meteor.call(...)
which doesn’t look to be what I’m looking for.
Currently I’ve managed top optimize Blade dependencies with heavy nonreactive() usage. But probably will still have to rework the code using Optimistic UI to make it more elegant. Hope your suggestion will help.