views:

1105

answers:

5

I've been reading up on this subject for a while. Suddenly the day has come where this solution is a necessity, not just a dream.

Through my reading, I've seen the popular differences being (file based, memcached, shared memory (mm), sql table, and custom).

The idea we originally thought of was using a ZFS or AFS mounted on each of the application servers (LAMP boxen), and pointing the session.save_path php.ini variable to a directory from that mounted path.

I'd like to hear of success stories.

Thanks in advance

A: 

I think storing your sessions in a database (like MySQL or PostgreSQL) will involve the least headaches, especially if you already have a DB for whatever it is your app does.

Memcached may also help, since it can store data across multiple machines, but I don't have any experience with it.

Justin Voss
A: 

I'm a bit biased, but I'd recommend HTTP_Session2. (I'm working on this package) While we support traditional session handling through files we also support database (MySQL, PostgreSQL, SQlite etc. through PEAR::MDB2) and also memcached.

Personally, we use the database-handler and we serve up to 100,000 users/day with no larger issues. I think optimization-wise, I'd go memcached next, but database is great for an intermediat fix which doesn't require you to bendover backwards. :-)

By the way, for more info on memcached, please check my answer on How to manage session variables in a web cluster?.

EDIT

Since you asked, here is an example (more in the API docs):

$options = array('memcache' => $memcache);

Where $memcache is an instance of PECL::Memcache, which is required. I know we lack an example, and we'll improve on that. In the meantime, our source code has pretty good documenation inline, so for example the check out the API documentation.

Till
Hi Till, Nice suggestion. I'm leaning away from the sql sessions handling. Memcached looks like a better way to go. I looked through the documentation for HTTP_Session2 and noticed there is a container for memcached, but I don't see what the $options parameter requires. Any help?
Phillip Jacobs
I added an example. This should get you started.
Till
A: 

I have been using file based on sessions on shared servers for over 5 years with no problems. We have some sessions that can become quite large (>10MB) and file based works very well. Typically our shared servers store the session files for each site in chrooted directories so only root can access them all. We have found this to be very reliable and have had no problems. Although you loose some of the functionality of database or memcached, there is a reason why it's the PHP default.

Darryl Hein
+1  A: 

John Campbell's answer here should help

http://stackoverflow.com/questions/76712

The point he makes about NOT using only Memcached is important.

Also, as I mentioned in that question, you may want to consider the session clustering that comes with Zend Platform - but there are significant licensing costs associated with that solution.

Peter Bailey
A: 

If you're looking into a Memcached solution for sessions - maybe you should check out Repcached. Should reduce any problems with losing sessions if servers get rebooted, etc.

about repcached
"repcached" is patch set which adds data replication feature to memcached 1.2.x.

Note: I haven't actually tried repcached yet, but thought it was worth looking into.

leek