Setting up memcached on Cloud Sites

By: Adrian Otto

This tutorial explains how to access a memcached server running on (one or more) Cloud Servers from Cloud Sites. Using this approach you can leverage all of the features of the Cloud Sites application platform, and all it’s related scalability while still enjoying the benefits of memcached at the same time. Note that Cloud Sites and Cloud servers are currently provisioned in the same data center together, so network latency will be low which means throughput will be high.

Step 1: Set up memcached on Cloud Servers

Use my tutorial on setting up memcached on cloud servers to complete this step. You can skip step 6. You can also skip step 5 if you want to run a default configuration.

Step 2: Set up a Test Script

I have included an example PHP script for using memcached from Cloud Sites. You can download it, edit the $server_hostname variable in the script to refer to the address of your Cloud Server, rename it to example.php, and upload it to your Cloud Sites account using SFTP or FTP. Once it’s uploaded, you can see how the caching works.

About Security

You must recognize that memcached comes with no security controls. Its possible for a hacker to dump the contents of your cache, or potentially access or change the data in the cache if they know what the address and port of your memcached server are, and what keys you are using. I suggest that you use a non-standard port number for memcached, and prefix all of your keys with a 10+ digit string that you keep secret. If you are highly motivated, you can make a custom version of memcached that has the ‘flush_all’ command disabled.

I can save you a bit of work. Here is a custom patched memcached 1.4.0 x86_64 RPM I wrote that adds a command line option ‘S’ to disable ‘flush_all’ and ‘stats detail on’ . The original 1.4 source, a SPEC file for RHEL5 and CentOS5 and the patch are both included in the SRPM. By disabling these commands with the -S option in /etc/sysconfig/memcached (OPTIONS=”-S”) you can prevent would-be hackers from dropping all your cached items, or finding out what the names are of the keys you are using. The memcached maintainers want to do this a different way, so this patch won’t be included in the base memecahced source tree.

You might also be considering the restriction of access to your memcached instance by IP address. If you plan to use it from Cloud Sites that will be difficult because you won’t know what IP addresses your connections will come from, and they could change without notice. Furthermore, any other user of Cloud Sites would be coming form the same IP address. For this reason, it’s best to simply use the custom memcached version mentioned above and a secret key text that you prepend to all of your keys.

Completion

Congratulations! You’ve set up memcached on your Cloud Sites account! Now it’s time to begin using it in your web application to add speed and scalability to your application and start saving money!

  • Was this article helpful ?
  • Yes   No
Adrian serves as a Distinguished Architect for Rackspace, focusing on cloud services. He cares deeply about the future of cloud technology, and important projects like OpenStack. He also is a key contributor for and serves on the editing team for OASIS CAMP, a draft standard for application lifecycle management. He comes from an engineering and software development background, and has made a successful career as a serial entrepreneur.

8 COMMENTS

  1. Hello, since I spent some time running some tests (including a production server), I thought that I would share what Cloud Sites and Memcached may look like.

    The *good news* is that it works, and it’s pretty to get up and running. You can even use Memcache as a service products like Memcachier.com and (soon) RedisLabs.

    The *bad news* is that while Cloud Sites is located in the same DFW datacenter as some of the Cloud Server instances, it takes multiple hops (9 in my case) to go between Cloud Sites to any Memcache instance on Cloud Servers – I assume that the same would be true for Cloud Database etc…

    This creates added latency that can be quite dramatic: a Memcache
    read/write from Cloud Server to Cloud Server (2 instances) can take as little
    as 0.25ms-0.70ms (to be fair, these 2 servers may be in the same rack, or the same physical server). With Cloud Sites, it can take 2.5ms-5.xms.

    There is a near 10X difference. Multiply that by dozens or more requests and it compounds quickly, making Memcache effectively “regress” the performance, despite caching about 88% of all MySQL requests.

    The second issue that I bumped into is that the Memcache PHP library on the Cloud Sites nodes are version 2.x. There’s a known bug visible in WordPress which makes the edit pages go blank, or missing. It is documented here. The libraries 3.x do fix it, but Cloud Sites is still running with 2.x as of today (4/12/2015)

    More info here:
    https://wordpress.org/support/topic/plugin-memcached-object-cache-problem-editing-posts

    Anyway, I would like to thank the tech support for providing some background
    data to help us understand what’s was exactly going on.

    We would *love* to pay to have managed Memcache servers/appliances accessible from within the Cloud Sites network environment. This would also alleviate the MySQL server load that Rackspace is currently providing is part of the same package – food for thoughts 🙂

  2. Hello, since I spent time running some tests (including in production), I thought that I would share what Cloud Sites and Memcached may look like. The good news is that it works, and it’s pretty easy to get up and running. You can even use Memcache as a service products like Memcachier and (soon) RedisLabs

    The bad news is that while Cloud Sites is located in the same DFW datacenter as some of the Cloud Server instances, it takes multiple hops (9 in my case) to go between Cloud Sites to any Memcache instance on Cloud Servers – I assume that the same would be true for Cloud Database etc…

    This creates added latency that can be quite dramatic: a Memcache read/write from Cloud Server to Cloud Server (2 instances) can take as little as 0.25ms-0.70ms. With Cloud Sites, it can take 2.5ms-5.xms. There is a near 10X difference. Multiply that by dozens or more requests and it compounds quickly.

    The second issue that I bumped into is that the Memcache PHP library on the Cloud Sites nodes are version 2.x. There’s a known bug visible in WordPress which makes the edit pages go blank, or missing. It is documented here. The libraries 3.x do fix it, but Cloud Sites is still running with 2.x as of today (4/12/2015)

    https://wordpress.org/support/topic/plugin-memcached-object-cache-problem-editing-posts

    Anyway, I would like to thank the tech support for providing some background data to help us understand what’s going on.

    We would *love to pay* to have managed Memcache servers/appliances accessible from within the Cloud Sites network environment (work with the Memcachier guys, they provide a secured way to do this).

    This would also alleviate the MySQL server load that Rackspace is currently providing is part of the same package. MySQL load is about 80% of all the tickets we file in the past 5 years – food for thoughts 🙂

LEAVE A REPLY