Interesting question.
I'd say that anything that can be done to use a pure RAM based solution would probably be the best fit for this type of problem. Mysql has a RAM based storage engine but that aside, memcached and redis both has automated data expiry and probably has superior performance, so I consider them a better fit. See Redis expire and memcached expiration.
If you can make sure that you only hit stuff in RAM, I believe you have won half the battle.
Besides that, try carefully evaluating how frequently you really need "pings" from the clients. If the user is idle, is it then necessary that the clients sends a ping every 10 seconds? Is it possible to handle user interaction after a session expiry gracefully? (Such as having the user click a button and the system then responding something along the lines "you are already logged in, please close the other window". This could work if the users aren't spending a long time writing things into forms, only to discover that they have been logged out once they submit.)
What is the worst case scenario?
Try this scenario:
| time | Client 1 | Client 2 | Server |
| t0 | Log in | | |
| t1 | | | Authorize client 1 session |
| t2 | Send ping | | |
| t3 | | | Update client 1 session |
| t4 | | Log in | |
Lets say that the time between t3 and t4 is 1 second. In that case what happens next is:
| t5 | | | Server rejects client 2 |
And if the time between t3 and t4 is 20 seconds and the ping interval is 10 seconds, we'll assume that Client 1 is gone and:
| t5 | | | Delete client 1 session |
| t6 | | | Authorize client 2 session |
But you could use a model with much longer ping intervals, and introduce a possible delay before the client is logged in. Given that the ping time is 60 seconds and the time between t3 and t4 is 30 seconds:
| t4+30| Send ping | | |
| t5 | | | Server rejects client 2 |
Or - if client 1 is gone,
| t4+30| | | Delete client 1 session |
| t6 | | | Authorize client 2 session |
But this delay will only take place if there has been a recent login from another client, so if the typical use case has only one client per user, it won't pose a serious problem.