The idea of using memcached on my shared hosting account had been bouncing around my head for a while; especially on my DreamHost shared hosting account. There are periods when the performance would suffer because of other users on the server, and I was also looking for a general increase in performance without having to pay for an expensive dedicated server. I should start off by saying that what I’m about to explain only works if you have a VPS or Dedicated server that you can access already. It may seem redundant for a tutorial or howto guide on how to get memcached working in a shared environment if you already have a VPS available, but the practice and procedures will be useful to allow you to run other customer PHP modules on DreamHost shared hosting. In my case, I already had a VPS server I use for Irssi but was not configured to be a web server. It’s a stripped bare DreamHost VPS with sudo / root access, and a handful of IRC applications running in screen. I had stumbled across this deal, for $5/month (on top of your regular DreamHost bill) when they were beta testing VPS servers and I had volunteered for an account; somehow my account got tagged with the discount, so I decided why not and added one to the account. Not only that, I didn’t want to deal with the migration of switching my accounts over from the shared server to the VPS; the “seamless” transition they have setup is fairly deceiving; I find that it usually borks up the websites in the transfer and requires a fair bit of mucking to get everything working again.
The first obvious problem, even before you go about installing memcached support modules for your web application, is that DreamHost’s default PHP modules for their shared hosting environments do not include memcached. Later I found out that they also don’t have a build of Imagemagick, but the procedures in this guide will apply to also allow you to install Imagemagick on your own.
Before we dive in and get our hands dirty, here’s a little background about memcached and why we want it. Memcached’s website says this about what it is:
memcached is a high-performance, distributed memory object caching system, generic in nature, but originally intended for use in speeding up dynamic web applications by alleviating database load.
The gist of the issue is that PHP is a dynamically interpreted language. Unlike traditional languages like C or Java, you don’t “compile” it, you leave it as source. When someone stumbles on your website, the request for the page pulls the source code into the PHP interpreter, which then compiles it and executes the code before sending the result to your happy web visitor. Because the code is pulled, compiled, and ran each time someone visits your website, there is usually a pretty significant overhead as your PHP slowly stumbles through the compiler. This effect is especially bad for intensive CMS systems like WordPress, which is being used on this very website.
Memcached aims to speed the process up by caching frequently used objects that your PHP code uses – in the case of WordPress, this is achieved through the use of a plugin that queries the memcached server for a cached version of the object before recreating and recompiling the object from scratch. Even with the overhead of checking before creating the object, this results in a significant savings in compilation and execution time. The tradeoff is higher memory usage (space-time tradeoff). The memory usage isn’t really significant for a single user, but can easily balloon if there’s high-traffic website that is hitting the cache often. For this application, I’m just using memcached with the default cache size of 64mb.