views:

161

answers:

4

Tracking online users is a very common requirement for any web application? I have the following questions related to this topic.

I would like to capture the following parameters:- lastAccessedTime - The time when the user visited the site the last time (usually shown during the login process) isOnline - A boolean to represent if a user is online or not.

a. Would it make sense to have these variables as part of the User table itself or should this be handled via a separate user audit table?

b. If certain SOAP / REST API's expose the functionality via API calls, how do you track the above parameters (e.g. Would you modify the lastAccessedTime in such cases - this might confuse the user if he logs into the portal, isOnline bit also will not make sense if the user does API calls).

Kindly clarify

+3  A: 

Make the lastTimeActive a field in the user table, and update it with each page access. Your "Users Online" list is all users whose lastTimeActive is within 5 minutes.

Jonathan Sampson
+4  A: 

I would create a session table that links back to the user. Instead of an isOnline field, I would just run a query for sessions that have been active within the last x amount of time. I would also update that session field with each request, even if that request is coming through an API.

This does create some overhead in pruning the session table, but you also don't clutter up your user table with non-user information, which can't be pruned.

Myles
+1  A: 

I would create another table (userid, lastTimeActive), and frequently update & check the table.

// update
update onlineusers set lastTimeActive = getdate() where userid=1234

// check
delete from onlineusers where lastTimeActive < dateadd(minute,-5,getdate())
Anwar Chandra
Oh no... that's horrible... it will kill your server...
Faruz
I maintain a portal with more than 1000.000 users. But there is only 100 online users at a time (less than 1%). It's better to select/update/delete new table rather than querying User Table.
Anwar Chandra
A: 

The biggest problem with tracking user presence (onine/offline) over HTTP is how to determine when the user has gone offline.

It's easy to determine when the user has come online - the mere presence of an authenticated request assumes that the user is active. However, since HTTP is stateless, the lack of a subsequent request can mean either that the user is gone offline, or that the user is online, but just hasn't done anything specific with your app recently.

Thus the best guess you can make is to have a timeout and if the user has not made a request during that timeout, to switch to offline state.

The simplest implementation would be to have a lastTimeActive, as Jonathan Sampson suggested. However, this won't give you the length of the user session, only an approximation of who's online at this moment.

More complex approach would be to have lastTimeActive and lastTimeLoggedIn. LastTimeLoggedIn is set at the time of first auth request that is more than 5 minutes from a previous auth request. A user is considered online, if there was an authenticated request in the last five minutes. The session length for the user is the time difference between lastTimeActive and lastTimeLoggedIn.

If your app also offers the choice of logging out to the user, you chouls consider that action also as going offline. However, unless your app is a banking app, chances are the users will just close their browser.

Also, avoid any background threads for updating the offline/online status of your users. You should be running the logic above only when there's an explicit request about the status of particular user and you should be updating only the users you were asked for.

Franci Penov