From my previous experience with burst testing, is that once I cleared the CPU spikes by spawning more VMs, the bottleneck was with Mongo Atlas response time slowing down proportionally to the number of writes per seconds. An indication that this might be issue is because you’ve two exact queries showing very difference response time.
I don’t see the DB logs, do they’ve consistent response time?
Hello Meteor pals,
I experience the same issue (some long fetch slowing down all server), so here are our thoughts about it :
1 - I don’t think this problem is linked to CPU spikes (in our case) : last time it occurred Kadira showed ~ 5% CPU (!) on the server that was slowed down. Same on our server monitoring tool, cpu was very low. And no RAM spikes either.
2 - Mongo seems fine too. The db monitoring does not show any unusual spike or saturation. No strange logs on the db side, and the support team of our mongo provider did not see unusual stuff at the time. Besides, we have 3 servers pointing on the same DB and only one server was affected by those slownesses.
But we do see a few request (publication and methods) occuring simultaneously, with wait time increasing exponentially. At the time of the problem, there was no this.unblock on publish or methods.
So I was wondering if there is a way to debug some kind of queue in Meteor just before querying db ?
Thanks 