Is It Recommended to Store PHP Sessions in Memcache

Is it recommended to store PHP Sessions in MemCache?

1: YES. And I strongly recommend storing PHP sessions in Memcached. Here's why:

Memcached is great for storing small chunks of data that are frequently accessed by the database and filesystem.

Memcached was designed specifically for sessions. It was originally the brainchild of the lead developer of livejournal.com and later used to also cache the content of users' posts. The benefit was immediate: most of the action was taking place in memory. Page load times greatly improved.

Thankfully, PHP and Apache have an easy implementation to handle sessions with Memcached. Simply install with a few shell commands

example for Debian:

sudo apt-get -t stable install php7.4-memcached

and

change your php.ini settings to something similar to:

(taken from https://www.php.net/manual/en/memcached.sessions.php)

 session.save_handler = memcached
 ; change server:port to fit your needs...
 session.save_path = "localhost:11211"

The key is the session.save_path

It will no longer point to a relative file path on your server.
APC was mentioned - APC for the caching of .php files used by the program. APC and Memcached will reduce IO significantly and leave Apache/Nginx free to server resources, such as images, faster.

2: No

3: The fundamental disadvantage of using Memcached is data volatility

Session data is not persistent in Memcached. So if and when the server crashes, all data in memory is lost. Everyone will have to log in again.

And then you have memory consumption...

Remember: the sessions are stored in the memory. If your website handles a large number of concurrent users, you may have to shell out a little extra money for a larger memory allocation.

Using memcache as a session store?

You would need to set up memcache to run on one of the servers and have all of the servers use that same memcache instance for the sessions. Otherwise, if they each run their own memcache instance, you'll have the same problem as before.

Other than configuring memcache accordingly and telling PHP to use it as your session handler, you shouldn't have to make any changes to your code.

~

To clarify the advice I gave here, if you group all three servers into a single pool, you won't have any problems as long as every PHP instance references those servers in the same order. memcache uses client side hashing, so you will be guaranteed that the same key is read / written on the same server. Of course, if you alter that list in any way, then sessions will become invalidated.

The memcache developers actually don't even recommend that you use memcache for storing session data because it isn't persistent, and thus if you have to restart memcache (or something happens), then all of your users will be logged out.

Using memcached to store session data, is it safe?

I wouldn't suggest using Memcached. The cache can invalidate at any time and you'll end up loosing data. I would recommend you use a solution such as Redis.

What happens to PHP sessions stored in Memcached if the Memcache instance hits its memory limit?

Memcached will use least recently used (LRU) eviction to free up memory. For this reason Memcached, or any cache for that matter, should not be used for long lived sessions (it is fine for short lived sessions).

For long lived session you should use a permanent storage such as a database. If performance is an issue you can emulate write-through caching by caching the session queries (this is what Django's cached_db session storage does for example). I am not aware of any write-through implementation in PHP but it is easy enough to implement.

mySQL AND memcached for PHP sessions?

I refer you to Dormando's oft-cited explanation of how to store sessions in MySQL with memcached caching. The original LiveJournal post is more wordy but more thoroughly explains why storing sessions in memcached only is a bad idea.

In short:

• Read session data from memcached first, look in MySQL on a cache miss.
• Write session data to memcached on every update.
• Only write to MySQL if cache data hasn't been synced for 120 seconds or so.
• Run a periodic script that checks MySQL for expired sessions. For every expired session, update from memcached and only expire the ones that are truly expired.

Session VS File VS Memcache for a Cache in PHP?

Memcache is your best bet for a lot of reasons:

1. It's REALLY fast - Everything's in memory, and it's highly optimized for situations just like yours (and caching in general :)
2. It's distributed - This means that if you have multiple web / app servers running, they can all access the same cache
3. You can pool multiple servers for memcache - If you've got a few servers that are relatively underutilized (or several dedicated cache servers), you can pool them all together into one big cache
4. It's super-scalable (for the reasons mentioned prior)
5. It's got great PHP support - The PECL package for memcache was recently updated with a lot of new goodness
6. You can even store your user sessions in memcache - just set it up in your php.ini file. This is much faster than storing sessions in databases, and allows your sessions to persist across multiple web hosts (if you're in a load balanced situation)... this will also give your site a bit of a performance boost as there's no need to hit the filesystem / database for session info on every request.

... and many more ;)

As to some of your concerns about memory footprint of individual cached items you've got a few options. My initial thought is to just give it a whirl, see how big these cache items really get (you can find several open-source things to monitor the actual cache usage, such as cacti). I think they'll be smaller than you'd think.

If they're not, I'd suggest re-thinking your cache strategy as far as what you actually cache, for how long, etc. Maybe you could build the feed from several things already in the cache (i.e. cache individual user data, and then build the feed for a person from all those individual items in cache). There are a lot of good articles out there on that front, just search 'em out :)

---

Related Topics