Using new PECL Memcached extension for storing session data

Many of you already know that managing session is a critical task for web applications, specially when you want to avoid I/O hop and also a significant load over your database by writing a custom session handler. Beside that, if your application makes use of multiple web servers behind a proxy, then its more than a critical job to share and manage session data among these servers effectively. This is why a central session manager is very important for your application to scale. In this article I am going to show you how you can use the latest Memcached extension (developed by Andrei Zmievski and his team) to isolate the session storage from web servers. I will show you how to compile the extension and use it.

Step1: Install Memcached Server
If you are using Debian its just plain simple

apt-get install memcached

Step 2: Run memcached instances
Lets run two instances of memcached in same machine (well, this article is just for demonstrating you how you can get things done. In the production environment, you can deploy as many memcached instances as you want in different servers in same network)

memcached -d -l 127.0.0.1 -p 11211 -u <username> -m 16
memcached -d -l 127.0.0.1 -p 11212 -u <username> -m 16

Above commands will run two instances of memcached listening on port number 11211 and 11212, same IP 127.0.0.1. Each of them get an allocation of 16 MB of memory (on RAM).

Step 3: Install the PECL Memcached extension.
Lets install the new PECL memcached extension in your web server. This new extension depends on libmemcached. You can grab the latest distribution of libmemcached from https://launchpad.net/libmemcached and compile it in your own machine. Make sure you have the dependencies met.

wget http://launchpad.net/libmemcached/1.0/0.34/+download/libmemcached-0.34.tar.gz
tar -zxvf libmemcached-0.34.tar.gz 
cd libmemcached-0.34
./configure
make && make install

Considering everything went fine, lets install the PECL memcached extension

pecl install memcached

If everything goes fine, you should see the output similar like this

Build process completed successfully
Installing '/usr/lib/php5/20060613/memcached.so'
install ok: channel://pecl.php.net/memcached-1.0.0
configuration option "php_ini" is not set to php.ini location
You should add "extension=memcached.so" to php.ini

Make sure that memcached.so is placed in your PHP extension_dir folder (here /usr/lib/php5/20060613). Add the line “extension=memcached.so” in your php.ini and restart your web server.

To make sure, everything’s done and working – run a phpinfo() and check the output. There should be a “memcached” sesction which will look like the following one.

Memcached PECL Extension

Memcached PECL Extension

Now we need to make change in our php.ini to register Memcached as a session handler and set the necessary properties there. Open your php.ini and add the following two lines. If you find any similar line un-commented, comment them out first.

session.save_handler=memcached
session.save_path="127.0.0.1:11211, 127.0.0.1:11212"

Restart your web server. And …… you are done! :) – Now all your session data will be saved and served from these memcached servers. No matter whenever you need to extend your setup by adding extra web servers, all user data and session data will remain valid and served from a central location. No I/O issue, no huge write load on DB servers.

About these ads

24 thoughts on “Using new PECL Memcached extension for storing session data

  1. Nice write up. There are a couple of points which should be clear though before using memcached to persist session data.

    Memcached stores all the data in memory so if the memcache daemon stops all the session data is lost. Moreover, specially if it’s used to cache other stuff besides session data, once the configured cache memory is filled “older” data is dropped from it to leave space for the new one. So it should be monitored to avoid session data lost on busy servers.

    Another issue to have in mind is that in a memcached cluster, the server where the data ends up stored is calculated by the client, so if we have multiple PHP servers they must have the same servers configured in session.save_path, in exactly the same order. Besides, if we add or remove a server from it, it might potentially trash all the current session data, since the client might end up asking the wrong server for the session data. These kind of changes should planned in advance and either warn the site users or dump and prime the sessions after the change.

    So I would advice against using session.save_handler for memcached support in servers with high loads. A custom session handler (using PHP code) which uses memcached to speed everything up but also persists the data to a database instance or a shared directory offers a more reliable solution while having a very small overhead, specially for small session data, over the memcached native save_handler.

    • @DrSlump,
      Thanks for nice comment, much appreciated. The points you’ve mentioned above are valid, but shouldn’t be more of a problem if you give these session servers a decent amount of memory, plus if your sessions are not active infinitely.

      If you set expiry time for user session explicitly to 2 days, for example, it will expire the cache in 2 days. and for a decent memcached server with 4+ GB of allocated memory it shouldnt be a burden for even a higher traffic. And the beauty is that you can extend your node anytime.

      If you want to offload the data somewhere, for example, MySQL – the problem of using multiple DB or read/write load will persist. One good alternative could be using MySQL memory engine.

      Btw, yeah – it requires a well planned architecture first :) – This article is mainly for demonstrating the process.

      Have a good day.

    • Memcached is a caching server actually, not a web server. It is used to store data temporarily for caching and offloading other business critical processes.

  2. If you are NOT on the “cloud” why not use memsession extension – it is way better for the session purpose & thread-safe … but even then Mohawksoft’s solution is preferable.

    memcached is just a multi-useless solution …

    cheers

    • Rhyno: Bolt, I can be a valuable addition to your team!

      Bolt; I’m listening …

      Rhyno: I am lightning quick, I’ve razor sharp reflexes, and I am a master of stealth. Plus, I’ll keep the cat in check

      Bolt : The road will be rough

      Rhyno : I have a ball

      Bolt : There’s no turning back

      Rhyno : Guess I’ll have to roll with the punches

      Bolt : Easy wont be part of the equation

      Rhyno: Promise?

      Bolt: gotta warn ya, going into the belly of the beast, danger at every turn,

      Rhyno: I eat danger for breakfast

      Bolt: you hungry?

      Rhyno: STARVING – mu ha ha ha ha

      Bolt: Welcome aboard …..

      @Martin Nikolaev – honestly, never heard of that extension. And I am listening ….

      And I would love to say “Welcome aboard…” too – have any benchmarking or feature comparison article around?
      :) – I just choose one of the very best solutions. May be it’s a multi-useless solution depending on how someone gonna use it, but it fits perfectly for me and million others out there.

      But, at the end, I am still listening…..

      Thanks.

  3. memsession (or the mm session handler) are obviously faster than memcached, since they don’t have to use the networking stack to store/retrieve data. Problem with those is that they don’t solve the clustering of PHP servers without using an “sticky” load balancer. So, for those deployments where PHP is being run on a huge machine (like an IBM Power System) it’s going to perform way better than memcached.

    Be aware though that most literature online about optimizing PHP is based on “cloud” style scaling on commodity hardware, so documentation and even support for extensions like memsession is scarce at best, and usually require trial-and-error and going thru the extension’s source code to fine-tune them.

  4. thanks for the good article.

    am I wrong or doesn’t memchached need a lot of coding to do anything.

    the impression I get from your article is that it is “automatically” caching stuff. Is that really so?

    I tought you had to do like so in code:

    memcached::add($key, $val, $ttl)

    and then retrieve the object stored by using the key.

    Is memcached an “auto-cache” of sessions on top of what I just wrote?

    This is somewhat confusing :)

  5. @Ritzo

    In this process, you dont need to write a single line of code if you follow the instructions available here. Session Data will be automatically handled by PHP+ Memcached Extension to store session data and successfully return it to the caller routines.

    You will use regular session code like
    session_start();
    $_SESSION['key']=’value’;
    :)

    :)

  6. How about session locks?

    With regular sessions you get a file lock on session file and two parallel scripts can’t mess with a session data. How that is managed in this case?

  7. I usually opt to store transient session data on a tmpfs partition – that way, you get the best of both worlds. It’s faster than memcached – and more stable than a 3rd party extension.

    Additionally, eAccelerator (and other op-code caching engines) has an in-memory session handler.

  8. @Ritzo Use of memcached for sessions is just one thing you can do with it. It’s one option along the way. Memcached really shines when you start to integrate it with your applications. For example – let’s say your web page parses an RSS feed for display as part of your web page. You are probably doing that parsing on every load. You can dramatically reduce the load on your server by doing that parsing only when a memcached get fails to populate your output variable.
    In pseudocode, it would look something like this:
    if (!$parsedresult = memcached.get()) {
    $parsedresult= LongExpensiveParsingProcess()
    }
    echo $parsedresult

  9. Well , the view of the passage is totally correct ,your details is really reasonable and you guy give us valuable informative post, I totally agree the standpoint of upstairs. I often surfing on this forum when I m free and I find there are so much good information we can learn in this forum!
    ..http://www.ipolos.com ..
    ,’,”,.╱◥██◣”o’,”’,,’,.”.”,,’,.welcome to come|田|田田│ ”,,’,.’,”’,,’,.”╬╬╬╬╬╬╬╬╬╬╬╬╬╬╬╬╬╬

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s