In addition and in response to Radarek, memcached is needed in very high traffic websites, no database or amount of servers can keep up with the major social networking websites, which is why this technique now exists and is getting more and more popular. Even without non transactional support, databases crumble under even only hundreds of hits per second (which typically can mean tens of thousands of queries per second).

Anyway, this is a nice quick tutorial I came across awhile back and was in my bookmarks and thought I’d comment on. Cheers

1000 users online at one time, every people make 1request/s so you have 1000requests/s (it is very huge value, believe me ).

If you query database only one per 2 minutes you have only: 2000 (1 select, 1 update) queries per 2 minutes = 16.66 queries/s. You can set time to 5min and have only 6.66 queries/s. Use simple table with non transactional support (MyIsam in mysql) and performance will be ok .

So, why I think that your approach is bad? There is some ‘race condition’ problem. If there will be many concurrent request in one time it could cause that some information won’t be saved in memcache. Another problem will be for many users online. Assumie that your array with users activity information has 500kb. Your php script must retrieve 500kb from memcache and put it back. For many requests/s it could be bottleneck.

Bottom line here is that it’s not a super-critical operation; it’s never going to be 100% accurate, but, in my opinion, that’s the nature of “Who’s Online” functionality. Accuracy is more important when something like, say, web-based instant messaging comes into play. If you IM a person that’s supposedly online, but they’re not, you’ll never get a response back, so it’s misleading.

In my opinion, it’s far better to store this data in Memcached rather than a database. That said, in our case, we are placing this data into the database in our back end batch processing script, but that’s just to support a certain accessory page.

Remember the goal here…keep those operations off of the database. For our needs, this works really, really well because it doesn’t have to be 100% accurate. That said, it’s done a damn good job so far. The lossy nature of it may be more apparent with thousands of users online, though, but we’re not there yet.

You may have 5 reads, then 5 modifies, then 5 writes. So only 1 user will be added to the array.

If it’s okay to have this be “lossy”, then that may not be a tragedy. But it’s definitely an unsafe operation unless you implement some locking. Which is of course more expensive.

There’s also the issue that if you’re using a cluster of memcache servers and you experience an outage on the one to which your cache key hashes, you will lose the online user list because the memcache client library will failover to the next available server. When the failed server comes back online, you will lose the online user list again, perhaps picking up the very old stale copy (if the outage was just a network partition). memcache restarts will lose the data, as will memory pressure from other cache entries. There’s no way to tell memcached to treat an entry as permanent.

In general, it’s a bad idea to store data only in memcached. It’s mem*cache*d, not mem*store*d.

And not doing locking is one of the reasons why memcached is faster than a RDBMS