Meteor - login method is very slow

[vbelolapotkov]

Hi, meteor community.

I’m looking for help with very strange login behavior.

After upgrading app to 1.4 experiencing login method can take (not always) too much time.
Most of the time it spends on fetching user from db:

There are not so many users in db (up to 500). And other searches (including further searches against the same collection) take much less time.

Tried to monitor mongo with mongotop during long login: it shows less than 10ms read time.

[hexsprite]

I’ve seen this too. I kinda doubt it took 65 seconds to do that query so I suspect there’s some Kadira bug perhaps that is attributing something else that is taking a long time to this query.

You could check basic things like: - do you have an index on emails.address? If you do db.users.find({‘emails.address’: ‘whatever’}).explain() can you learn something?

[vbelolapotkov]

Well it wasn’t 65 seconds agree but still it takes too long.
Regarding the index. Will check it. However I noticed exact same result when fetch is made by _id which is always indexed. Strange thing is there is no such delay on staging environment where servers have less power.

[vbelolapotkov]

here is the result of explain():

"winningPlan" : {
	"stage" : "FETCH",
	"inputStage" : {
		"stage" : "IXSCAN",
		"keyPattern" : {
			"emails.address" : 1
		},
		"indexName" : "emails.address_1",
		"isMultiKey" : false,
		"isUnique" : true,
		"isSparse" : true,
		"isPartial" : false,
		"indexVersion" : 1,
		"direction" : "forward",
		"indexBounds" : {
			"emails.address" : [
				"[\"belolapotkov.v@gmail.com\", \"belolapotkov.v@gmail.com\"]"
			]
		}
	}
},

As I understand it has index.

[vbelolapotkov]

For those who have similar problem.
DB logs investigation showed that db response time wasn’t longer than 12-15 ms.
Downgrade to meteor 1.3.5.1 did the trick. All used packages were restored to pre upgrade versions as well.
So I don’t know what was the root cause of the problem meteor core or 3rd party package =(

[jcacabral]

Hi, buddy.

I’m going through the same problem here, running on 1.3.5.1 meteor version.
It happened only once, before it had never happened

Here is my logs from Kadira.

Is ocurring in: observeChanges on users - AND - observeChanges on meteor_accounts_loginServiceConfiguration

It seems that everything is normal, but something has occurred in the login attempts that stuck the application.

Thanks for any help.

[vbelolapotkov]

@jcacabral I haven’t experienced the issue since I rolled back version. Unfortunately I wasn’t able to find the root cause as the issue was only in production environment. Currently I’m running 1.3.5.4, maybe minor update will be able to help you.

The only thing bothers me in your screenshot is a warning regarding the disabled oplog. How is your mogodb deployed?

[jcacabral]

It was deployed by Mup (legacy).

I’ll try a minor update. Thanks.

[evolross]

Did you ever figure out what the root of this problem was? Have you updated to Meteor 1.4 or 1.5 yet with no issues?

I’m having the same issue. My production app slows to a crawl when a lot of users hit the server at the same time (more than fifty or so). And Meteor APM (formerly Kadira), like you, shows a really long wait time on observeChanges on meteor_accounts_loginServiceConfiguration when I look at the stack trace for meteor_accounts_loginServiceConfiguration. And other stack traces of meteor_accounts_loginServiceConfiguration show it waiting for really long periods of time on multiple async steps.

I’m on Meteor 1.2.1. I’m wondering if I should update to see if that resolves it.

If you’re curious: https://forums.meteor.com/t/mongo-scaling-issues/27905/54?u=evolross

[vbelolapotkov]

Hi @evolross, unfortunately no. I wasn’t able to reproduce the issue in any other environment as well. I’m still on 1.3.5 and the app is doing well. I have plans to try the upgrade to 1.5, but not in the nearest future.

[koticomake]

Did anyone found the root cause for the issue?
This is strange I am on meteor 2.0 and still getting this behavior. Not just with login, APM is also showing DB queries on other methods taking time.
Which were really not taking any time in DB (They are proper indexed queries) But APM somehow shows that those queries took a long time to run.

[peterfkruger]

Do you use MongoDB Atlas in production? It turned out to be the culprit for being intermittently slow to the extremes in some incidents.

[koticomake]

Thanks for your reply @peterfkruger
Yes, we use MongoDB Atlas. But when I look to MongoDB Atlas there are no slow queries logged in performance advisor.
Do you have references or blogs discussing MongoDB Atlas being intermittently slow to the extremes in some incidents?
Just asking to make confirmation and take a decision accordingly.

[peterfkruger]

Strange phenomenon: Subsequent methods or subs won't succeed

I noticed a strange phenomenon that happens every once in a while on our production server: If the users open up the app for the first time, they can execute a Meteor method as normal, everything works fine. But when they try to execute the same Meteor method again or if a subscription is updated, the server won’t respond anymore. The UI gets stuck because of this. If I reload the browser page, I can execute one method again. Then the same problem repeats. It feels as if the DDP connection does…

The ultimate reason for this problem was an issue with Atlas. Someone else later reported a similar problem, and if I recall correctly, that was also caused by a paid tier Atlas cluster, and so only appeared in production.