Hi Meteorites, curious if anyone has seen slow subscriptions after the upgrade to Meteor 3. I think the image is self explanatory in showing when I upgraded. I only have 1 user and 1 subscription to Meteor.users retrieving only the _id field, some counts and email. The image doesn’t show it but I had response times up to 30 sec.
I host computing with AWS and DB with Mongo Atlas.
This isn’t good. Could this be a specific issue with the host? Is the performance consistently poor?
You said this started after the upgrade from 2.15. Have you seen this level of degradation with previous versions like 2.x?
I understand that we still have some performance tasks pending to measure the upgrade’s impact. These tasks might shed light on whether the problem truly exists.
Never had this problem with this code in 4 years. The moment I upgraded, I started to see this. In the first image you can observe the difference in subscription times over 7 days and I upgraded and pushed to live on the 22nd in the evening. There are 2 cases though, with different levels of performance and I am not sure how these 2 cases differ.
I am already signed in and load the webapp (I have a Meteor.userId() client side but not a Meteor.user()):
A) The subscription is called before I am connected. I can see I get connected … later I get the subscription data and I can see a Meteor.user().
B) The subscription is called after I am connected. I am already connected to the server, and … later I get the subscription and I can see a Meteor.user().
I am already in the webapp not signed in. I go to sign in. On a successful sign in, I call the subscription and receive my data instantly.
I expect my observation will add to the general state of confusion related to the matter
If you are using Monti APM, there’s a couple things you can check when there are slow queries.
In the system dashboard, you can check if the Event Loop Latency was very high at the same time. If the event loop is blocked for a while, it can make queries look much slower than they are. The other chart is Mongo Primary Pool Connection Checkout Delay which is the delay between the code starting a query, and the driver having an available connection to run the query.
Both numbers are probably fine, but it’s worth checking to eliminate those causes.