• Where’s the Bazaar tree on launchpad? I hate pulling tarballs, following the dev tree is much more interesting from a tech perspective (especially for early development releases). I note that the NDB memcached stuff is up on launchpad now, so yay there. I would love it if the InnoDB team in general was much more open with development, especially with having source trees up on launchpad.
• It embeds a copy of the memcached server engines branch into the MySQL tree. This is probably the correct way to go. There is no real sense in re-implementing the protocol and network stack (this is about half what memcached is anyway).
• The copy of the memcached engine branch seems to be a few months old.
• The current documentation appears to be the source code.
• The innodb_memcached plugin embeds a memcached server using an API to InnoDB inside the MySQL server process (basically so it can access the same instance of InnoDB as a running MySQL server).
• There’s a bit of something that kind-of looks similar to the Embedded InnoDB (now HailDB) API being used to link InnoDB and memcached together. I can understand why they didn’t go through the MySQL handler interface… this would be bracing to say the least to get correct. InnoDB APIs, much more likely to have fewer bugs.
• If this accepted JSON and spat it back out… how fast would MongoDB die? weeks? months?
• The above dot point would be a lot more likely if adding a column to an InnoDB table didn’t involve epic amounts of IO.
• I’ve been wanting a good memcached protocol inside Drizzle, we have ,of course, focused on stability of what we do have first. That being said…. upgrade my flight home so I can open a laptop… probably be done well before I land….. (assuming I don’t get to it in the 15 other awesome things I want to hack on this week)

View full post on Planet Drizzle

Read more on Developer.com

Read more on Developer.com

Usually the main reason for doing this is because of sessions. For security reasons your browser will not keep you signed in with the same session if you hop subdomains. What this means is that if you logged in on www1.example.com and now go to www2.example.com the browser will consider this as two separate sites and you would have to login again on www2.

People used to play a number of tricks to remove session stickiness such as storing sessions in the db so that they could transparently load balance your session across multiple webservers. However databases due to their inherent nature are often large monolithic beasts that are much slower than some of the alternatives available out there now.

One of these, which I am a fan of, is memcache! The folks over at danga.com have given us one of the most powerful building blocks for creating highly scalable websites.

We can now experience load balancing as it was meant to be!

As an example lets take PHP session handling. PHP usually stores its session on the local hard drive of a server. You can also make it store sessions inside a database, lets say MySQL. However, as I mentioned earlier MySQL is very slow compared to memcache and is inherently harder to scale compared to memcache.

To setup PHP to use memcache for sessions, this is all you have to do :

0 – Install memcache library available at http://pecl.php.net/package/memcache

1 – Open php.ini

2 – Set session.save_handler = memcache

3 – Set session.save_path = “tcp://IP:PORT&weight=X” where X is the weight of a particular memcache server. You can add as many as you like by specifying one after the other separated by a comma.

4 – Install memcached. For a distribution like Fedora or CentOS just execute “yum install memcached”

All of this should not take you more than 5 minutes, and you are done!

Now to scale just keep adding more servers and firing up the memcached daemon  and experience the true beauty of completely transparent load balancing .