Hi!
Just wondering what the community uses for the disconnectTimeSec value for the mixmax:smart-disconnect package ?
I understand the default is 60s.
What are your values and why did you make that decision pertaining to how your apps are used?
Have you noticed it’s led to positive performance impact for your users?
Thanks!
Would love to know if this package is used in the community as I have never heard of, if it can disconnect properly idle connection it can be great
Think of situations where a user switches to another tab in the browser or brings something else in foreground.
Could be:
On reconnect, your client resubscribes to the previously active subscriptions and gets the updates.
I think 60 sec is the right time to wait for a user to come back. If you expect few concurrent users, 5-10 minutes is also fine.
I’ve heard about it for some time as it’s frequently mentioned in posts and blogs about optimizing Meteor performance and scalability.
I just implemented it on Production but set the Time to 4hrs.
I wanna see how the community is using it too
great points!
we’re not overly concerned with reactivity or showing notifications on a tab.
That being said, we have some expensive subscriptions that a user may not want to wait to reload for.
I have some things to test and consider. But seems like anywhere from 1-10min should be fine
#1, for browsers, it does not make sense to set this to longer than 5 minutes as browsers like chrome will automatically kill background tabs after such duration anyway
#2, this is outdated as the page visibility lifecycle has been updated: Page Lifecycle API | Web | Google Developers
Even if browsers kill the background tab, does that mean Meteor still has the connection between the client and server open though?
No, the client will be disconnected. But the main problem is with the reconnection as Meteor will not always automatically reconnect when the tab becomes active unless the user refreshes the browser tab which is a big usability issue e.g. some clicks requiring connection will stop working. It does not always reconnect using this package because of the unsupported page visibility state as I have posted above
Yes I have this problem in my app, after some time you have to hit refresh when coming back, is there any way to avoid this ?
Call Meteor.reconnect() on resume, pageshow, and focus
We’ve been leaving connections active and noticed some get orphaned. On the server, I can see the number inch up over a few days. Bouncing the server will often clear many of them.
@rjdavid – you think the page being disconnected, with the tab or browser later closed, is causing this?
As well, my understanding is HCP relies on having an open connection. Any disconnect – I was thinking of disconnecting on idle login pages – will need to confirm HCP is complete first, yes?
@gdc3 I am not aware of how or where to track orphaned connections. Is this available in the APM?
Regarding HCP, I believe that Meteor handles this during disconnection and reconnection although admittedly, it has been a year since I have created a Cordova app
@rjdavid – Our users subscribe to a hairy query that then cascades to grab additional data. Despite a bunch of dramatic performance tuning, this makes things still pretty server intensive.
I suspected a leak upon seeing our server consistently falling over with the same kind of weird error after 7-10 days of up time. I added to the Meteor.onConnection and connection.onClose callbacks to count sessions and track type (actively logged in or just passively open on login page).
We rarely see many of the latter but I do see the number of active sessions grow. It doesn’t only go up, but the number trends up over time. A server bounce resets the count to something much lower – hence me thinking orphaned sessions.
You’d think the sockets heartbeat would terminate a frozen client, but that doesn’t seem to be happening in all cases.
So @rjdavid are you using something to close connections or not really as it is not relevant with new chrome APIs ?
In terms of disconnections, we are doing something like what is in the package: calling Meteor.disconnect() after a set time.
Ok thanks will the look at the code and adapt