Mixmax:smart-disconnect disconnectTimeSec values


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?


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

1 Like

Think of situations where a user switches to another tab in the browser or brings something else in foreground.
Could be:

  • a user has opened a new link (in a new tab) from inside your app, is going “away” to that tab to read the content. The user will take some time to read or just close the new tab and come back quickly to your app. 60 sec. seems a good time to wait for the user to decide.
  • a user moves to a new tab for a while. In FB or Whatsapp on web, or in other networks, if you get an update inside your app, the browser tab shows the number of new notifications. If your app is disconnected you will not see that.
  • a user has left your app opened in a tab and forgot about it entirely. You would probably want to disconnect that.
  • others…

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.

1 Like

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

1 Like

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

1 Like

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 ?

1 Like

Call Meteor.reconnect() on resume, pageshow, and focus

1 Like

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?

1 Like

@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.

1 Like

So @rjdavid are you using something to close connections or not really as it is not relevant with new chrome APIs ?

1 Like

In terms of disconnections, we are doing something like what is in the package: calling Meteor.disconnect() after a set time.

1 Like

Ok thanks will the look at the code and adapt