I had some thoughts back ago about using memcached for session storage, but came to the conclusion that it wouldn't be sufficient in the event of one or more of the servers in the memcached pool were about to go down.
A hybrid version is to save the main database (mySQL) from load caused by reads would be to work out a function that tries to fetch the data from the cache pool, and if that fails gets it from the database.
After putting some more thought into it, I started to think about using APC cache for session related data. If our web server would go down, sessions would be lost either way, so storing them in a local APC or a localhost memcached server maybe isn't that bad?
What's your experiences?
Generally, session data is something which should be treated as volatile in any situation. The user can always choose to eliminate the cookie themselves at any point (if you are using cookies, of course). For this reason, I see no problem with using memcached for session data.
For me, I'd just keep it simple - no need for a DB fallback unless you absolutely must never lose the user's session in the event of a memcached server failure. As I said at the beginning, I always treat sessions as purely volatile in any case and don't really store anything of any significance in them.
That's my two cents anyways.
Related
I have a PHP system that i'd like to port to be on more than one server if the need arises. Currently I store the user's current session information just in the default manner PHP does (assuming in memory). Can I get an example of what I need to put in a table in my MySQL database as well as some example of implementation?
The default session storage system is actually on the file system. Some system caching may be used to pull it from memory.
Now in order to go into a multi-server setup, your servers need to basically share nothing with each other. To that goal, sessions need to be stored outside of the server they are created and accessed on.
Storing sessions in the database is one option, but it increases the load on your database and you have to be careful with locking in some cases. Default session handling has locking which allows only one thread to access a given session at a time, a database handler may not do that. If you are only reading session data, this is likely not going to be a problem, but if you are changing it, it could be.
The memcached extensions allow for session data replication to memcached nodes. I prefer this route as it allows you to keep sessions in memory and avoids adding extra db load (which is often more difficult to scale)
My application can store up to dozens or even low hundreds of KB of data in the session. I'm currently storing PHP sessions in MySQL blobs, and traffic volume is now putting session-related queries on the database around 25-75 per second. It's causing some problems.
Is there a centralized storage option for PHP sessions of this size that will perform well? I'd prefer to avoid sticky sessions at the load-balancer level if possible for other performance reasons. I can try to reduce the session size, but regardless I'm going to need this information on most requests, so I'm going to have to stash it somewhere.
Scache is ideal for that. You can probably split your session data to smaller parts, some might even be cacheable to all sessions and so on. Scache has api for all that.
There's nothing bad in big session data, it's bad only if you store it to $_SESSION.
memcached is always a favorite option.
The memcache PHP extension helpfully comes with a session handler that will store sessions with memcached.
Zend's own session cluster daemon:
http://www.zend.com/en/products/server-cluster-manager/high-availability
For a high traffic web site we are planning to scale up to use 2 web servers in a HA setup.
One issue we will need to tackle is the management of PHP sessions.
The obvious answer is to move session handling to the DB which is easy and example code is widely available ton the internet.
On the other hand we are aware of the benefits of memcached but once a memcached node fails, users on that node will lose their session.
So we are thinking of implementing a setup where sessions are handled in memcached by default but also written in the DB. When we get a memcached MISS we would try to also retrieve it from the DB.
Does the above make sense and are there any implementation examples you are aware of?
thanks in advance
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.
Sessions it's a temporary thing, there is nothing to worry about if once per month memcache-server will fail and truncate sessions. I'm sure you can use just memcache for sessions, without replication in DB.
But if you still want to dump sessions to disk, as existing solution you can use Redis:
Redis works with an in-memory dataset.
Depending on your use case, you can
persist it either by dumping the
dataset to disk
...
Redis also supports trivial-to-setup master-slave replication, with very
fast non-blocking first
synchronization, auto-reconnection on
net split and so forth.
I was thinking about using memcached to store sessions instead of mySQL, which seemed like a good idea, at first.
When it comes to the failover part of utilizing memcached servers, It's a bit worrying that my sessions will stop working if the memcached would go offline. It will certainly affect my users.
There's a few techniques that we already utilize to reduce failover, including having a pool of servers available to compensate in the event of downtime, utilizing sharding/consistent hashing across the server pool and so on. We would also do some sort of graceful degradation that tells the users that something have gone wrong and they are welcome to login again, in the event of them being kicked out due to memcached server failover.
So how does people generally deal with these issues when storing sessions on memcached servers?
First, if you put something in memcache only, you should be OK losing it. For everything else, there's persistent storage.
Second, memcached simply doesn't fail very often. There aren't any moving parts like disk platters. The only times I've ever lost sessions were due to reboots for kernel upgrades. But losing those sessions weren't a big deal, because of the first point.
So to answer your question directly, if a datum is OK to lose, storing it in a memcache session only is OK. If it's not OK to lose, store it in persistent storage, and maybe cache it in memcache for speed.
You could create a fail safe method by using both the db and memcached. Check to see if your memcached object is in memory else store session in the db then create the memcache instance. Just make sure when log out / sign out, it flushes/removes the memcached...
So check memcached first, if fails, check db... :)
I am trying to create a more secure PHP sessions login script. Unfortunately for this project I will be working with shared hosting. Would using PHP's session_save_path() function to change the path to something other than /tmp be a secure solution? Or do I need to save the sessions in the database?
Thanks!
Personally, I prefer storing sessions in the database because it not only circumvents some of the file access slowdowns associated with using a file-based system, but also gives you more direct and "supervised" methods of managing the direct session data.
Consider, if you implement using MySQL, using the Memory (HEAP) Storage Engine as it will give enormous performance benefits. This, of course, is assuming you are unlikely to have thousands upon thousands of active sessions, and that your session data is "volatile safe," i.e. if a sever crash causes session data to be lost, the worst that should happen will be that users are asked to log back in.
Moving the session save path is a good start. Just make sure its not in the document root.
With some shared hosted I've observed that getting a database connection can take a second or two. Storing your sessions in the db could slow the whole app down. Your session is accessed twice per page load.
You may want to test both an see which performs better.