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.
For those who have similar problem.
DB logs investigation showed that db response time wasn’t longer than 12-15 ms.
Downgrade to meteor 184.108.40.206 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 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 220.127.116.11, 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?
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.
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.
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.
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.
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.