My app was recently upgraded to Galaxy Metal. This upgrade was eagerly anticipated and is a significant improvement in many ways.
However, I experienced a particular issue where I would get re-subscription “storms” every 30 minutes causing performance degradation for my users. Turns out that Galaxy Metal uses HAProxy servers that have a default policy of killing every client socket older than 30 minutes. Before Meteor 3.5.0, this disconnection causes a Meteor app to open a new socket and resend the full set of subscription data to the client (i.e. the server lost the session context). My app is quite “hungry” on subscriptions and so it resulted in a significant uptick on subscription volume on a continual basis.
My Blaze app also has numerous {{#if Template.subscriptionsReady}} guards that suppressed rendered content until the subscriptions were ready and thus, for any user, the app could appear to “refresh” every 30 minutes as the subscriptions became unready as the refresh took place.
I’ve now got a patched 3.4.1 Meteor version that back-ports the 3.5.0 feature that allows Meteor to retain the session context during a temporary (15 seconds) disconnection - so now my clients don’t resubscribe to their complete data set every 30 minutes! I’ll use that until I upgrade to 3.5.1.
Additionally, I also had a guard, sometimes, on Meteor.status().connected that tore down the template and replaced with a disconnection warning. Even with this Meteor patch, the status is still blipping off and on, so I’ve had to replace it with a (more sensible anyway) test that checks for a longer lasting disconnection (5 seconds in my case).
Galaxy tell me that a “kill every socket over 30 mins old” is fairly standard and I can imagine it would be in many cases. But is it really appropriate for Meteor apps? Should we be killing perfectly healthy and active sockets? Are there not protocols to be slightly more selective - like killing sockets with no activity for 30 minutes?
Anyway, that’s one question that’s worth contemplating. But, secondly, has anyone else been affected by this? Or wondered why they are resubscribing every 30 minutes? If so, now you know ![]()
Meteor 3.5.0 now survives the socket cycle better without a re-subscription, so if you’ve upgraded already then it’s less of an issue.