Are PHP sessions hard to scale across a distribute

Question

At work we do almost everything in Java and perl, but I wanted to build out a feature using PHP and sessions. Some peeps thought that it was a bad idea to try to do PHP sessions on our system, cause it's distributed to many servers. What would the specific problem be?

Answer 1

The answer to your specific question, what would the problem be, lies in the fact that by default PHP stores its sessions in files on the filesystem. For a single webserver serving requests, this is not a problem because your session data will always be available. But what if you had two load-balanced webservers serving requests?

Imagine hitting the first webserver with a request, which creates your session file on its file system. Then, your next request hits the second webserver. The second webserver will of course not see the session file. To the user, you might log in to a website, and then suddenly be logged out.

This is not a problem specific to PHP, and is very common. The solution is to store session data in some common area. The most common method for this is to store session data either in a database accessible to all web servers, or some shared memory cache server like memcached.

Answer 2

Quite a vague question, but I would say the problem is bigger than mentioned in the answers. Sure you can override how loading and saving cookies, but there's a cost to it, too. For example, you will have to consider the following scenarios/questions:

• If you are putting the cookies on another host, how will this affect the speed of your cookies? That obviously depends on how many writes/reads you make.
• Are you doing this to increase speed or to have failover? The answer will definitely lead to different solutions:
  • In case you are doing this for failover, how will you handle if your webserver(s) can't access your session store because network link goes down? What if your session store goes down? You will have to solve this using some kind of master-master replication, possibly running that distributed session store on the same machine as the webserver for extra high availability (if all sessions can fit in memory). Have a look at Riak or similar for master-master replication.
  • In case you are simply doing this for speed, I would use apache, nginx or (fastest) haproxy to simply do load balancing based on client IP address. That way you don't have to bother with setting up a distributed session store. Sure, if one of your PHP-instances goes down your users will loose their cookies, but maybe that's not a problem. It's up to you.

Answer 3

You could also use a custom session save handler:

http://www.php.net/manual/en/function.session-set-save-handler.php

I haven't ever tried it, but with it you define your own save/read functions, so you can implement a database or a shared nfs backend without the need to install any extensions.

Also Msession, which was suggested by @Eran Galperin, looks very interesting as an alternative to the one I mentioned before.

Answer 4

easiest is memcached or redis.

here is how to do it in redis - we are using it at the moment: http://redis4you.com/articles.php?id=001&name=Redis+as+session+handler+in+PHP

Answer 5

Persisting sessions across several servers (also known as session clustering) is a common problem for scaling web applications, and is not specific to PHP. PHP does offer several solutions to handle it, such as the Zend Platform (commercial application server), and Msession (extension).