PHP on several servers with session-sharing

load balancingmemcachedPHPredis

there's certanly other threads about this, but I have one more question.

We are about to scale the website at work to have more than one server. And we need to share the sessions between the servers.

We have been looking into different solutions, one in memcached and use Memcached as sessionhandler in PHP. That will probably work.

And the idea would be to run memcached on every machine and let all webservers access all other servers memcached servers, and then we have shared sessions between the machines, yay. (we have no resources to setup with sticky-sessions yet, that's a later project. we need this running, and we need this running now. and we will loadbalance with DNS for a starter)

But then… If I want to take one server down, say, for maintenance, or a server crashes, or whatever reason. I don't want the users to just loose their sessions and have to start from the beginning… That's why we need some kind of replication, which Memcached does not support.

Then I found http://repcached.lab.klab.org/ — which has multi-master replication of memcached, which is great, and is what I want. But does it work with >2 machines? Say 3, 5, 10? For future scaling.

I also looked into redishttp://redis.io/ — which also seems great, but is a bit more "shaky" with the php-session-handler support, and no multi-master-replication.

The thing is that I like to use memcached, but I want to be able to power down one of two boxes without loosing half of the sessions. Any suggestions?

Best Answer

You might want to have a look at couchdb which implements replicated key store with a memcache API. It also handles overflow of the memory storage more gracefully than most memcache implementations (a likely outcome during failover). I must admit that I'm not familiar with the details of how it implements replication.

All the implementations of 'sticky' sessions I've seen bind the request to an explicit device - which does not make for good failover - and with PHP the session affinity is only relevant to the storage substrate (unlike in Java where it usually needs to be at the logic tier). So using sticky sessions at the HTTP tier is irrelevant.

Certainly using asynchronous MySQL replication in the substrate is not trivial due to replication lag and single thread write operations - I use a connection broker in PHP (which implements preference and blocks during failover) to address this. Although MySQL is not the most efficient solution for session handling, if your applications are already relying on a high-availability relational database, then it makes a lot of sense to use it for session storage. There are multi-master replication implementations for MySQL - e.g. Percona.

MongoDB also uses asynch replication, but without the single thread dependency of MySQL.

You're going to have to spend some time thinking about how you fence nodes. Virtual address takeover (if implemented correctly) should make the operation transparent, but IME it can be tricky to get right and it needs to takeover the arp address as well as the IP address to avoid big pauses during failover.

Say 3, 5, 10? For future scaling

If you're planning to scale to this extent, then you should probably be thinking about multiple data centres - which implies a synchronization method which can cope with low bandwidth / higher latency i.e. not a shared filesystem.

Related Solutions

Linux PHP Memcached – Memcache vs Memcached: Key Differences Explained

The short answer: Either one is what you are looking for, but my first choice would be memcache (the first one you listed), purely based on its correct use of nomenclature.

Now here's how I came to that conclusion:

Here is a quick backgrounder in naming conventions (for those unfamiliar), which explains the frustration by the question asker: For many *nix applications, the piece that does the backend work is called a "daemon" (think "service" in Windows-land), while the interface or client application is what you use to control or access the daemon. The daemon is most often named the same as the client, with the letter "d" appended to it. For example "imap" would be a client that connects to the "imapd" daemon.

This naming convention is clearly being adhered to by memcache when you read the introduction to the memcache module (notice the distinction between memcache and memcached in this excerpt):

Memcache module provides handy procedural and object oriented interface to memcached, highly effective caching daemon, which was especially designed to decrease database load in dynamic web applications.

The Memcache module also provides a session handler (memcache).

More information about memcached can be found at » http://www.danga.com/memcached/.

The frustration here is caused by the author of the PHP extension which was badly named memcached, since it shares the same name as the actual daemon called memcached. Notice also that in the introduction to memcached (the php module), it makes mention of libmemcached, which is the shared library (or API) that is used by the module to access the memcached daemon:

memcached is a high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load.

This extension uses libmemcached library to provide API for communicating with memcached servers. It also provides a session handler (memcached).

Information about libmemcached can be found at » http://tangent.org/552/libmemcached.html.

In summary, both are functionally the same, but they simply have different authors, and the one is simply named more appropriately than the other.

Php – memcached and PHP … massive lag with sessions

The problem is in the session.save_path syntax between memcache.so and memcached.so:

extension=memcache.so
session.save_handler = memcache
session.save_path = "tcp://127.0.0.1:11211"

vs.

extension=memcached.so
session.save_handler = memcached
session.save_path = "127.0.0.1:11211"

Note the protocol in the memcache one, no protocol in the memcached one.

Also, make sure you actually have the .so you are trying to load. They're two separate packages via apt-get or yum or whatever flavor you use.

Any breakage due to loading the wrong module or using incorrect syntax causes a 30 second load delay in php while it tries to use your session mechanism and eventually times out.

Hope that saves someone some time. ;-)

Best Answer

Related Solutions

Linux PHP Memcached – Memcache vs Memcached: Key Differences Explained

Php – memcached and PHP … massive lag with sessions

Related Topic