IllegalPigeon

Ah, I miss-read some things. Either way, my comment still stands. *IF* you have enough traffic on your site that means using cache to fetch something like the users health is actually beneficial (which I extremely doubt), then you're still going to be burning through mass amounts of memory. At which point, you'd need to add more servers dedicated to cache. Seriously, small things like user stats, you do not need cache for. Use cache for bigger objects/more complex queries. I understand the concern over reducing database hits, but, memory is also very precious and doesn't come in "unlimited" forms and, I assure you, you're going to run in to data being over-written because it's not been used in a long time.

That's not how PHP sessions work. Your memory is safe. You're over-thinking. There is such a thing as too much of a good thing, you know? Memcache is great, but it stores things in memory, it's all well and good using memcache but what happens when you exhaust all of your memory because you thought storing EVERYTHING in memcache was a great idea? A general rule of thumb to go by when storing data in memory is to store large queries, anything that does a large calculation or queries that have a habit of being slow for whatever reason. Storing tiny bits of data in memory is just pointless and you end up using more of that precious memory you need. Also, it's worth mentioning that memchase uses a "Least recently used" reclamation algorithm. This means that if you start to run out of memory, memcahce will start replacing stored objects that haven't been used in a while. If you're storing some small user bits like "general information", the user makes a small change say "username", then you don't use it in a while, it'll get over-written. Doing a data lookup in memcached isn't largely quicker than doing a database lookup. Cache is quicker, however, under high load, as it can handle more requests than your database can. I strongly encourage using memcache, just don't go over the top.