Spyridon and rjdavid,
Thanks for your help! We have not found the source yet but we have concluded it is NOT Atlas.
We’ve tried our exact same production environment that usually uses Atlas and switched it to a self-hosted, unused, test database and the readings were still around 1900ms (very high).
The only difference between the 1200ms tests (dev system) and the 1900ms tests (prod system) is the parameters we used for the user login (for the same user account).
So it seems there’s a difference there that has been causing a slow down of subscribes. We’re on the track to investigate that.
Thanks for your help and thank you for your encouragement to be rigorous 
3 Likes
Ok we found out.
It was really a code issue.
We did put in place the current monitoring system a couple of 2-3 months ago.
When a user logs-in in our app, we record some information (device, IP, etc). They usually connect between 5 and 15 times per week. But our system did it twice per minute…everyday.
When they login, the subscribe to that document but filtering out huge fields but the document being over 4MB still reduced login performances by a lot (now twice as slow). So cleaning that one document fixed everything 
Thanks for everything. We learned a lot and we’ll never have documents that can grow indefinitely.
Cheers,
Burni
1 Like
A proper deployment of Atlas Mongo for large scale projects should be done via internal IPs (VPC) and not public DNS. This documentation explains the procedure: https://docs.atlas.mongodb.com/security-vpc-peering/. When in the same VPC, network issues (latency, DNS resolution etc) are excluded when things are getting slow.
1 Like
Oh very interesting. That makes total sense. We’ll check that out.
Thanks Paul!!
BTW Meteor Cloud supports VPC peering so Redis/MongoDB and other connections can use the local network instead of the Internet to talk with your app
If anyone here wants to know more about it just ask in the support channel (support@meteor.com)
3 Likes