Updating user document is very slow on client while fast on server (same machine)

help
1

Hello,

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?

2

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.

3

Will try Kadira. Post results.

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 :confused:

4

On a shoddy WiFi network connection? Since it varies so much, I’d say that’s your best bet.

Kadira should show how much time is spent processing, networking and databasing(hah now that’s a word).

5

That’s what optimistic updates are for. http://guide.meteor.com/ui-ux.html#optimistic-ui

6

Gentlemen it’s a localhost, so WiFi latency should not be an issue.

7

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).

8

Veered, all, thanks,

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.

But :slight_smile: I’m totally mixed up with manuals. In example in Meteor tutorial http://guide.meteor.com/ui-ux.html#optimistic-ui there is a
Lists.methods.insert.call( ... )

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.

9

The call is defined here: http://guide.meteor.com/methods.html#advanced-boilerplate

10

Thanks!

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.