Does it make sense to disconnect clients (using Meteor.disconnect()) that have been inactive for a while, say when user doesn’t work with my app’s browser tab, but keeps it open in background? Does every client connected to server incurs overhead?
Although there can be a very extensive answer to this question, the basic reply would be that every client incurs an overhead because it represens an established websockets connection with your server over which, the meteor server keeps track of its active subscriptions.
There are a number of packages on atmosphere that help with user status/presence and idle/stale session information.
If you opt in to use one, make sure you are aware of the side affects (the way your app behaves specifically). Furthermore, if you are running your app on multiple instances, make sure whatever you choose works with multiple instances.
Say, my server current setup can handle 10k clients working actively concurrently with the app. And there are currently 10k active clients and 5k who are connected but inactive. Does disconnecting them has an impact in freeing up server resources to allow efficient handling of the rest 10k?
Yes, disconnecting those idle clients would help better utilize your server because it will no longer have to track them.
That being said, depending on your actual server throughput, the active users may or may not feel the difference.
What you could end up doing is, scaling down your server to match the requirements for a smaller userbase and save some bucks.
2 Likes
What are the ways to disconnect idle clients?
I use the konecty:user-presence package and with it, a client will disconnect itself after a certain period of inactivity, but I’m pretty certain this isn’t working a lot of the time. Disconnecting depends on a setTimeout completing on a client after 10 minutes or so. But I don’t think it happens.
Is there an effective way to ensure a disconnect after 10 minutes of being idle?