How digg (or other high load category websites) are storing user sessions?

Question

How does digg or any other high-traffic website store user sessions? What do they use for storing the user sessions? File system, DB (which one?), memcache or both?

Let's imagine a simple situation. Logged user has set the flag "Remember me" during login. We've set a session cookie with expiration date 1 year. For example, we are keeping session in memcache, but we also should keep record of this session in DB (in my version). Only users with "Remember me" flag are stored in DB. Is it a right way of storing sessions? I mean high traffic websites, of course (with 2 or more application servers, 2 or more databases, memecache servers etc.). In small websites storing session by default way (in file system) is ok.

I've tried to search google, but failed to find any information about it. I've read some solutions from "Advanced PHP programming" book, but main accent was made to customizing session storing handler.

Really hope to hear good ideas or links!

Thank you.

Answer 1

In addition to Alix's answer, you may be interested in checkout out this article:

• Memcached as a Sessions Store (etc) by a Digg employee (Nick: timeless).

A short excerpt:

What prompted the Memcached as sessions store:

Shortly after the rollout of Digg v3, the non-redundant MySQL session store hardware crashed. This led to a Digg outage. We had always planned that in such a case we would just roll a (trivial) change to put sessions into Memcached rather than MySQL to see how it fared.

---

So, before you were hitting the db every time for sessions?

Yes.

MySQL was plenty capable of keeping up with the inserts and selects done to deal with sessions. Our problem was actually with clearing out old sessions. The script to delete old sessions, despite being fairly sophisticated in its attempts to not overload the sessions database, still affected it.

We surmise that Memcached will remove expired sessions with less overhead than MySQL.

---

We used InnoDB for sessions [before memcached]. It wasn't table- or row-level locking. It was OS-level contention. Using Memcached in front of MySQL would've reduced the load and allowed the admin script to do its work, but that highlights the question: why even have MySQL behind memcached at all? We don't need or even want non-volatile sessions. (Important note to reader: you may need or want non-volatile sessions).

"Why even have MySQL behind memcached at all?"... "We don't need or even want non-volatile sessions".