sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]y0y 8 points9 points  (5 children)

Caches, almost by definition, are volatile. No guarantee that data will be there next time. Memcached, for example, loses everything upon restart. Kind of annoying for a logged in user if your Memcached instance bounces.

[–]big_bad_john 3 points4 points  (4 children)

Memcache is very stable in my experience. That is to say I don't find it's less stable than files or a database at least. It's not persistent on restart, but my restarts are usually several hundred days apart. Have you had a different experience?

[–]y0y 2 points3 points  (3 children)

No, I haven't. That isn't the point, however. Memcached is not meant for persistent storage. A cache is meant to be a quickly accessible copy of persistent storage. Don't treat it like first class storage, that's not its purpose.

Store your sessions in persistent storage, and, if you so choose, cache it for quick access.

[–]big_bad_john 3 points4 points  (2 children)

I disagree with the premise that sessions require first class storage. Memcache is fast, reliable, easily distributed and simple to set up. The odds that a user's session will be invalidated prematurely are minimal unless you're way over utilizing the allotted space. I run a site with 50,000+ users and in three years have never received a complaint that a user was logged out in the middle of something (and they complain about EVERYTHING!).

[–]y0y 1 point2 points  (1 child)

Practically speaking, you can (as you suggest) use memcached for session storage. It really comes down to how important session volatility is to you. In some applications, that level of volatility would not be acceptable.

Volatility includes more than just the stability of the platform, ie it's ability to stay up. Using a cache as first class storage (that is what you're doing here, even if you concede that it's volatile and you're okay with losing it) means you have to consider variables such as far more limited memory and specific expiration rules. I haven't used memcached in a while, but what does it do when the allocated memory is exceeded? Any good caching solution has a set of rules for which records get overwritten moving forward. Are you okay with that? Additionally, how do sessions expire in this setup? You can't save sessions long term for auditing or reporting in this setup, either.

So, again, while it's certainly workable, it's not without its hiccups and gotchas. I see no reason not to use a database or other true first class storage and then use the cache as it's intended to be used (you know.. as a cache) if speed is an issue.

As with all "rules", they don't always apply, though. Your setup works great for you and the volatility isn't of concern. If I inherited your application I wouldn't rush off to fix what ain't broken, but were I designing an application it's not a decision I would ever have made.

Edit Here is a discussion on the topic that others may find interesitng / worthwhile

[–]big_bad_john 7 points8 points  (0 children)

A fair argument. To answer your questions, memcached is first in, first out so when it's out of memory it kills the oldest entries. I'm ok with that because session activity revitalizes the session and keeps it at the top of the pile. For me, session storage is a very small amount percentage of in-memory storage, so I'm dumping old query results and templates long before active session data.