So to summarize, we’d developed a caching system and switched to memory-based caching. Our site was doing fairly well – rebooting the server on a semi-regular basis was a distant memory. But in early April 2008, we hosted the first ever Yale Daily News Web Conference, where we invited students from other Ivy League newspapers involved in their online operations to come and talk about putting a college newspaper online. It was a good time; maybe I’ll blog about it in the future.

At that conference, I hosted Thomas Bukowski from The Dartmouth for the night. He showed me some of what he had been doing for their site, including how he handled view caching. His work, which made his site serve very quickly on less powerful hardware than us, inspired us to implement view caching on our site. Now let me explain exactly what view caching is and why it’s sweet.

We were caching the data we retrieved from MySQL, which was the most expensive operation and saved us quite a bit of processing and immensely helped our server load. However, after we retrieved the data from the cache, we still had to generate the HTML we send to the user, including all of the conditional statements, loops and other code that take some time and energy. Instead, why not save the page that is generated and serve that, instead of going through all of the presentation code every single time? The idea is that as soon as possible in your code, you check and see if you have a cache available. If you do, serve the cache and stop processing. If you don’t, process the page and save the cache when you’re done. That way you don’t have to do it next time.

Sounds good in theory, but it takes a little bit of work. We started by putting our code in /path/to/app/config/bootstrap.php, which is the earliest place CakePHP is booted up and allows you to execute code. The first problem we ran into was that we allow users to register accounts and log in. If you do that, you can see a personalized welcome message in the top right instead of “Log In – Register.” If we cached the page with “Welcome Joe,” that wouldn’t be good for everybody else. The solution was to check and see if a session exists for the visitor – if so, we don’t serve a cached page. Fortunately, most people don’t log and set a session, so for everybody else we serve a cached page.

We also don’t want to serve a cached page if there’s form data being POSTed or GETed. So we check and make sure those two superglobal arrays are empty. If they are, we begin our caching logic. We check and see if the cache is set for this page. If so, we get the cache and print it out, and the page is served. We also print how long our code has been executing for up to that point in a comment below the HTML. If you’re not logged in, check out the bottom of the source. You’ll see something like “<!– cache took 0.0009s –>”. Not bad.

If the cache isn’t set, we start output buffering with ob_start(). Then, as the last code that executes after every page, we check if we’re buffering with the line “if ( ob_get_level() >= 1 )”. If so, we store the content into the cache. The next page that’s requested is served from our lightning-fast view cache. With view caching enabled, we were able to survive our perfect storm.

How could we make this even better? Well, nginx has the ability to access memcached directly. It could directly check if a view cache existed, and if so, serve it. Apache would never start and it would be unbelievably fast. That would involve switching from XCache to memcached, which is something we haven’t done thus far, but may do in the future.

That concludes my series on caching. Fin.

So as I’ve described, we got a system going where we were caching our data. Yes, we weren’t expiring caches very well, but the system was working and helping reduce load our on our server, so we were somewhat out of the woods with regards to our performance problems. It was at that point that we realized that somewhere along the way, eAccelerator had been disabled on our server.

Let me explain the purpose of eAccelerator. eAccelerator is what is known as a PHP accelerator. PHP is different from languages like C# and Java because it is interpreted, not compiled. When you write a C# program, you use what is known as a compiler (probably Visual Studio, though there are others). The compiler takes your source code and turns it into object code (also called bytecode), which can be more easily and quickly interpreted by the computer.

PHP is an interpreted language, like Python and Ruby. Instead of having a compiler that creates an executable with bytecode (the stuff that’s easy for a machine to read), when you visit a Web page, the PHP process starts up and goes through each line of the source code, compiling it to bytecode for every request. Doing this is complex and just like retrieving data from the database, ripe for caching.

eAccelerator lets the PHP interpreter run once, then saves the bytecode into memory. The next time a PHP script needs to be run, eAccelerator retrieves the bytecode from memory, and the PHP interpreter doesn’t need to run and do the complex parsing it normally would have to. Much faster – according to Wikipedia, 2-10 times as fast!

Well, somehow our eAccelerator installation on our convoluted cPanel setup had stopped working, and we needed to get another solution working. We found XCache, from the makers of Lighttpd. (At the time, eAccelerator hadn’t had a release in quite some time, whereas XCache development was quite active. For the record, I also hear good things about APC.) XCache solved our PHP accelerator woes, which was good.

However, it also offered variable caching. Instead of serializing data and saving it to a file, like our solution was doing at the time, we could instead pass in the data we wanted to save to a special XCache function. It would handle serializing the data and saving that data into its memory cache. There were also functions for retrieving the data, checking if it was expired, etc.

This was great! Let me explain why. I’m a “computing assistant” at Yale, which means I help students fix their computers and support their software and hardware issues. I’m very frequently asked about upgrading their computers or buying new ones. Whenever I give advice, I always recommend buying more RAM, as much as they can get. If you understand that accessing RAM is faster than accessing the disk, you can skip the following sidebar. But, if you’d like a hopefully easy to understand explanation, here’s how I explain why RAM is good to non-technical people:

Your processor is the brains of the computer. It’s very good at taking instructions and doing them very quickly. The hard part is getting instructions to it. It has some storage space available on it (CPU caches). Getting information from there is super fast, but there’s not much space, just a couple megabytes. Think of it like your desk – it’s very quick to reach over and grab the stapler, but there’s not enough room to store an elephant. The CPU generally keeps things it needs very frequently in this space, often the most basic parts of your operating system.

Then there’s your RAM. I recommend getting at least a couple gigabytes, which is many times more than what’s available right on your processor. You could fit almost anything in there, and it’s very fast. Think of it like your house – enough space for a couple elephants, and pretty quick to get something and bring it back to your desk.

The absolute last resort is your hard drive. Think of it like the United States of America. It’s massive – you can fit anything you want on here, and if you run out of room, just annex Canada (buy another hard drive for more space). However, it’s very very slow. You could have to drive across the entire country to pick up your elephant! That is why when your processor receives something, it tries to put it in your RAM. If you have lots of RAM, it can keep most of what it needs in there. If it runs out of room, then it has to go to your hard drive. Not good.

That was a long way to say that hitting the hard disk is all bad. With our file-based caching, we had to hit the hard drive for every caching operation! Instead, we could use XCache’s variable caching, which exists in memory. Now our caching operations read from and write to memory, which is much faster.

By far the biggest player in the memory caching space is memcached. It’s the big dog. It was developed by Danga for use at Livejournal, and now it’s used by everybody from Facebook to Youtube. We considered it, but I read that it’s actually slower than XCache because Apache has to connect to another process, whereas XCache runs in-process. That being said, memcached offers some advantages for multi-server solutions (and some nifty interoperation with nginx), so we may switch in the near future.

How does XCache avoid taking up all of available memory? We set an amount of memory that it can use. If it fills that up, it deletes the least recently used cache object from the cache to make more room. It never uses more than the maximum we allow. This is called the LRU cache algorithm.

So there you have it: how and why we switched to memory caching. One more left, and it’s a big one: view caching.

So as promised in parts one and two, this post will be about expiring caches. You want to know the secret of how we expire caches here at the YDN? The super-surreptitious algorithm? The answer is … we don’t!

Well, ok, it’s not exactly that we don’t expire caches. They do expire eventually. When we set the cache, we also set a time we want to expire. That could be 10 minutes from now, two hours from now or a day from now. Until that time, the caching helper will retrieve the data from the cache. When that time rolls around, it decides that the data is no longer valid and will regenerate the cache object.

What I mean by “We don’t expire caches” is that when editors make changes on the site, the relevant caches are not expired automatically. For example, let’s say an editor adds an article to the current issue. Ideally, it would show up immediately on the front page of the site. But since the data for the front page is cached, that article won’t show up immediately. It will have to wait until that cache expiration time rolls around; then it will show up.

Now, we do have a link that clears the entire cache. That invalidates all of the cache objects, so the entire site will be regenerated. We use that fairly often when we want updates to be reflected on the site immediately. But it’s not the greatest solution. Regenerating those caches is expensive; thus, clearing all of them is expensive. That’s why when we’re under load, I send out a “friendly” reminder saying “DON’T CLEAR THE **** CACHE!”

So why don’t we clear caches automatically? I know this is somewhat of a copout … but because it’s really really hard. This is mostly because of the way Cake returns the data from the model and how we’ve architected our caching system. The model returns an array of all of the relevant data. For example, our cache object for the front page looks something like this:

Array {
Issue { id:1,
Article {
{id:1},
{id:12345}
}
}
}

We save that array as our cache object. Now, let’s say an editor makes a change to article 12345. We would have to expire this cache. We’d have to expire the article page’s cache. Those are easy. But let’s say they change the headline. Is it in the most popular box? We’d have to expire that cache. Is it attached to a slideshow and cached in that slideshow’s cache object? As you can see, since our data is stored in so many cache objects, trying to expire them all doesn’t scale as a manual process.

One solution I’ve seen is to store in a separate field some metadata about the data in the cache object. So for the example above, store “issue_1, article_2, article_12345″. Then you can search through those to find which cache objects are holding things you need to expire. But that’s fairly slow and difficult to implement.

So we’ve basically decided that we’re ok having some data lag. Ideally, we’d have caches expire immediately. Maybe in the next complete rewrite?

Up next: switching to memory caching and view caching

In fact, these reporters have already posted to our new blog, “Inside the Dragon,” which you can visit at http://yaledailynews.com/blogs/insidethedragon. Entries will focus not as much on the sporting events as on Chinese culture, security, economics, food, preparation, youth, politics and (of course) Yale’s close friendship with the emerging superpower. But, don’t worry, with one current junior and five Yale alumni competing in rowing, sailing and fencing, our reporters cannot possibly overlook the competition itself.

Reporting projects such as “Inside the Dragon” are inspired and driven by reader contributions. So please, don’t hesitate to contact me anytime at editor@yaledailynews.com with ideas of your own. See you in the fall, when more exciting news from the Oldest College Daily will come your way.

Sincerely,
Andrew Mangino
Editor in Chief

In the first post, I posted some sample code of something we do quite frequently: check for the existence of a cache object, if it’s set then get it, or if it’s not set, set it and then get it. We do this all the time, basically every single time we use our caching system. To avoid having to type out all of that code every single time, I wanted to create a function to wrap that logic.

I’m not very imaginative, so I called the function doCache. It takes three parameters: a name, an anonymous function, an object and an expiration time. The signature looks like this:

function doCache($name, $func, $object='', $cachetime)

Let’s go through each one of them. The name is simple: It’s just the name that you want to set for the cache object. It could be issue_index, article_1, author_1000, mostpopular, etc.

Now for $func and $object. At the time I was creating the caching system, I was also becoming more advanced with JavaScript (which is really a fantastic language that gets a bad rap because of the problems browsers have with the DOM, but that’s another discussion). In JavaScript, you can pass anonymous
functions as parameters into other functions and they can be used. I tried to adapt this for PHP.

Something I’ve wrestled with in writing this blog is defining a target audience. For now, I’ve decided to expect readers to have a fairly good technical background. While I will try and explain the concepts relevant to what I’m talking about as best as I can, I will sometimes link to explanations for those that are too broad to go into detail in a blog post. For example, I linked to an explanation of anonymous functions above. If you aren’t familiar with them, you should read the linked page then keep reading this post – it may make more sense.

The best PHP offers is create_function, which is a feeble stab at anonymous functions. The function takes two parameters: arguments and the code to execute inside the function. For example, let’s take the following code:

create_function('$model', 'return $model->getHomePage();')

That parameter is passed into doCache in the parameter $func. You also need an object to pass into the anonymous function so you can use it. That’s the third parameter of doCache. It’s frequently a model object – in this case, it’s the Issue Model, which retrieves the data for the home page. (I explain models a bit in the first caching post.)

So now inside doCache, if you call $func($object), $object is passed into that function as $model. The second parameter of create_function is the code you want to execute. So the getHomePage function of the $object, which as we said above is the Issue model, is called. So, if you had the code “$data = $func($object);”, $data would be set to the results of the getHomePage function.

There are two reasons why create_function is pretty bad. First, instead of just passing in a function, you need to pass in parameters to a helper function (the create_function function), which is unnecessary. That results in a second frustration point: If you have any quotes in your code, you have to escape them. Otherwise, they terminate the outer quotes of the second parameter, which are holding all of the code being passed into the second parameter of create_function. Very annoying.

The final parameter is $cacheTime, which is how long we want the cache object to live. My next post will discuss expiring caches, but basically, it indicates how long a $cacheHelper->get() should return the data before that object is considered invalid and must be generated again. In this example, it’s set to a default, but you could pass in a different value. I’ll get into it more next time.

So how does the final function look? Let’s check it out:

function doCache($name, $func, $object='', $cachetime=$default) {
    if ( $this->issetCache($name, $cachetime) ) {
        return $this->getCache($name);
    }
    else {
        $data = $func($object);
        return $this->setCache($name, $data, $cachetime);
    }
}

And a sample call:

$data = $this->Cache->doCache('issue_index', create_function('$model', 'return $model->getHomePage();'), $issueModel);

That one line of code makes our caching system work. All we had to do was go through our code, find all of the slow function calls (since we try and practice fat modeling, we often had just one function call to get all of the data) and wrap them in doCache. That helped ease the process of implementing the caching system across the site.

Up next: expiring caches, switching from file system to memory caching and view caching (the jackpot).

When I started making the Yale Daily News site, I had very little experience working with caching. Before, I really only had experience with small-scalle Web sites. The YDN operates on a slightly different scale. In order to handle that kind of traffic, we’ve had to work very hard to implement many performance enhancements. This post describes how caching has saved our site numerous times.

Our performance problems began in February 2007, just a few short weeks after the current version of the site launched. I naively thought that bandwidth and disk space were the only metrics that mattered. That’s not the case! CPU usage and memory are very important to handling lots of visitors to your site! That may sound extremely obvious, but if you’ve only worked on shared hosts before, you might not think about that. We were on Dreamhost, which I had used successfully for many smaller sites. But the YDN site is large and complex, and generating each page is resource-intensive. We were Drudged in early February, and Dreamhost notified us that we had outgrown our account and needed to move.

I then decided to order a dedicated server from Softlayer. We moved to that server, which was much more powerful, and ran acceptably there. Our load was still fairly high, hovering between 1.5 and 2, but we weren’t crashing. However, as we added more features (and thus more complexity) to our pages, performance became a more serious problem. The traffic our China blog attracted in May 2007 exposed these problems even further, and I had to reboot our server more than once after excessive traffic made it crash. We needed caching badly.

Summer finally arrived, and though I was busy with an internship, I had some time to turn my attention to caching. I actually attended a SuperHappyDevHouse event in late June 2007 (I’ve never felt so geeky in my life), and while sitting there watching people hack in Lisp and Ocaml, I came up with the initial caching implementation for the Yale Daily News.

At first, I implemented data caching. At the time, we were running every SQL query on every page. While they were often very fast, there were frequently quite a few of them. (Such is the downfall of using an ORM like CakePHP provides for us – it makes development much easier but at the cost of often doing more than you need in order to accommodate all the use cases a framework needs to support.) Additionally, there are some queries we run (for example, getting the Most Popular stories or Frequent Coauthors), that are expensive and time-consuming. My goal was to cache the results of those queries.

What does that mean? Let’s take the home page as an example, as it’s the most-visited page, one of the most complex, and the one where I started. There is one main data call to the model that returns an array of all the data we need to generate the page. (A model is part of the MVC pattern and is in charge of modeling data, often a table in a database. If you’re not familiar with that, just understand that we called a function that queried the database for all of the data we need (issue, articles, authors, photos, etc.) and returned an array of all of it.) The goal is to run all of that code and SQL queries once, save the result, and then use the cache for subsequent views instead of running the complex and time-intensive code necessary to generate the results. How does that work? Let’s check out some example code:

if ($cacheHelper->isset(’indexData’)) {

$data = $cacheHelper->get(’indexData’);

}

else {

$data = $model->getData();

$cacheHelper->set(’indexData’, $data);

}

Let’s break that down line by line. $cacheHelper is a class I created to wrap all of the necessary caching logic. It has a function called isset(). That function checks the cache to see if that cache object exists. At first, we were using file system caching. That meant that we stored each cache object as a file in a directory. So for that example, we stored the data in a file called “indexData”. So isset() would check to see if there was a file called “indexData” in the cache directory. If there was, the get() function in the cacheHelper would read that file, and the code would store the results into data. If the file didn’t exist, the model would run its expensive getData() function, and then the cacheHelper’s set() function would create the file indexData and store the data in that file. The next time the code would run, that file would now exist, and the expensive $model->getData() line would never be reached.

What exactly was stored in the cache file? We store the results of PHP’s serialize() function into the cache object. When we read the cache object, we call unserialize() on the data. 99 percent of the time, we store an array, which is how our database data is returned to use by the model.

We put this caching logic into several important places on the site – the index page, the article page, the author page, etc., and saw massive improvements! Now, instead of running queries and sometimes taking seconds (years in Web server time) to generate the page, it would take well less than a second! Load dropped dramatically! Major improvements!

This is the first in the caching series. It got long so I decided to split it up. Look for future posts about the following:

• Wrapping that code up above into one function and how that exposes PHP’s lameness
• How we handle expiring caches
• Changing from file system caching to memory caching
• View caching – the motherload

Our model for a tab is simple. There is a wrapper with the class “tab” for the entire box, and then for each actual tab it is in the class “subtab.” Each subtab has a header with the class “subtabtitle” to display the title of the tab, and one more div with the class “subtabbody,” for the content shown when a tab is clicked. It looks like this:

<div class = “tab”>

<div class = “subtab”>

<h3 class= ” subtabtitle”> Title 1 </h3>

<div class =” subtabbody”> text in the first tab</div>

</div>

<div class = “subtab”>

<h3 class= ” subtabtitle”> Title 1 </h3>

<div class =” subtabbody”> text in the second tab</div>

</div>

</div>

The real problem is how one can use this basic design layout and convert it into our standard tab look and feel. The trick is to use JavaScript to traverse and modify the DOM (document object model) or, simply put, to rearrange the HTML. One of the best JavaScript tools to do this is Prototype. Prototype is easily installed and adds a host of more powerful functions to the standard JavaScript library. The most useful ones were related to tranversing the DOM. Two that I found particularly useful were the up and down functions. For example, if I am current at the subtab class element I can easily move to the h3 by typing:

var header = subTab.down(“h3.subtabtitle”)

I can make header move back up just as easily with:

header = header.up(“div.subtab”);

With this header variable one can use other great JavaScript and Prototype functions. One I used frequently was setStyle. For example, say I wanted to change the subtab class to be a font size of 12px, I could just write:

header.setStyle({
fontSize: ‘12px’
});

The one difficulty with using Prototype is that the Prototype functions return an object that uses both standard and Prototype JavaScript functions. However, standard JavaScript functions don’t return these objects. Therefore it is important to remember when you are working with a Prototype object and when you are using a plain JavaScript one. To solve this problem, be sure to wrap any variables with $(foo) to convert it to a Prototype element. Combining some prototype functions (the API is fairly helpful) with crucial DOM functions such as removeChild() and appendChild(). Also setStyle() function was very handy when I wanted to generate precise CSS on the fly (for example if there are so many tabs that they fill a line of the div, a new row of tabs are automatically created).

A final issue was that the JavaScript originally overlaid all the tab content but using CSS hid the content that wasn’t active. This was a problem when forms were in the content, because sometimes multiple empty or default forms would be submitted that the user could see. To solve the problem we set up a dummy property in each element that stored the HTML but wasn’t displayed on the page but could still be called on for retrieving content. This meant that the forms were actually not just hidden by the CSS; they were only added to the DOM when the user clicked on the appropriate tag and the old content was cleared.

Anyway, if you take a quick look, you’ll notice that our Server header is “nginx/0.5.26″. (Note: Don’t look on this blog; it’s not hosted on our production server. Look on YaleDailyNews.com.) Anyway, you might notice that’s not one of the two servers that run the vast majority of Web sites out there on the Internet - Apache and Internet Information Services (IIS). We used to send back Apache headers, but what is nginx?

To quote the English version of its documentation (it’s a Russian product), “Nginx (pronounced ‘engine x’) is a free, open-source, high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server.” Essentially, nginx is a FAST Web server. It’s great at handling requests for static files - CSS, JS, images, etc. Its downside is that it’s not very good at serving requests for dynamic pages: anything that involves parsing server-side code, which is PHP in our case.

So we decided to use nginx in what’s called a reverse-proxy. When you make a request to our Web server, nginx handles that request. It checks to see if the request is for a static file. If it is, it serves the file. That’s much faster than Apache! Under the old system, Apache was serving both dynamic requests, which it’s good at, and static requests, which in a LAMP configuration it is not very good at. In order to serve simple CSS files, it had to use its heavy PHP-interpreter-laden process to serve that request, which is quite memory-intensive and relatively slow. Nginx is much faster.

But what about dynamic requests? After checking to see if the request is static and serving it if so, nginx passes on all other requests to Apache, which is better at handling PHP requests. Apache is running on our server on another port, so nginx passes the request to localhost on that port. Apache sees that request, generates the page using PHP and passes the content back to nginx, which sends it back to you.

I wish we had better numbers, but we didn’t really do as much benchmarking as we should have. One of our main bottlenecks is memory (especially now that we’re doing view caching, which will be the subject of my next post), and nginx uses much less memory than Apache, so we’re able to serve more requests without overloading our server. I’d estimate a 20 percent increase in requests per second.

The other alternative we considered was moving our static assets to Amazon S3. However, in order to do so, we would have to do some reworking in our code to point to the right images location, we’d have to develop a deployment process to synchronize to S3 and we’d have to pay for Amazon’s bandwidth costs. We may revisit the idea in the future though, as well as considering moving to Amazon EC2 for hosting as well. However, for the time being, nginx was an easy and helpful solution.

Sorry about the delay. Posts should come more regularly now. I’m aiming for one every week, but don’t hold me to it!

There are several places around our site where we use MySQL’s DATEDIFF function, which calculates the number of days between two given times. One example is the “Most Popular” box, which shows the most popular viewed, e-mailed and commented stories on our site. That works by retrieving stories posted within the last week sorted by the relevant count (hitcount, emailcount, or commentcount). If there aren’t 10 stories within the past seven days, it will go to 14 days to try and fill the box, then 21 and so on.

The query we were running had the following WHERE clause: DATEDIFF(NOW(), articles.dateposted) < 7. That got back only articles posted in the last week. That worked like we wanted it to, but it was a bit slow. Instead of taking just a couple milliseconds, it would take about half a second. Remember that it has to do at least three queries to get all three types, and if it doesn’t find enough articles within the past week, it has to run the queries again with 14 days, then 21 etc. That really only happens over breaks though, when we’re not publishing daily. Regardless, even three queries taking half a second is a lot.

The problem was mitigated by the fact that we cache the results of our database calls. So we actually only generate that “Most Popular” box every couple hours, rather than for every request. So did I actually need to optimize it? Well why not! I enjoy do this kind of stuff, and it looked like a quick fix. I was reading some slides called Join-Fu by Jay Pipes, who works for MySQL. Slide 17 was particularly relevant. He was talking about date calculations and optimizing them. I thought of our “Most Popular” box and set about optimizing it.

The problem with our query was that it could not take advantage of two important parts of what makes MySQL fast: indexes and query caching. First, apparently queries with functions operating on a column means it can’t use an index. (Indexes are kind of a large topic to get into in this post, so I’ll just direct you to some reading on them.) Not using indexes means the query runs much more slowly. To solve this problem, I followed his advice and rewrote the WHERE condition to be “articles.dateposted > NOW() - INTERVAL 7 DAY,” using MySQL’s INTERVAL syntax. The time taken to execute the query dropped to around 100 milliseconds - 1/5 of what it was!

But because the query still had a function in it, MySQL has to evaluate the result when the query is executed and therefore couldn’t cache the results of the query. Again, query caching is a bit outside the scope of this post (more reading on it), but at the basic level, MySQL caches the results of queries it executes, so the next time they’re run it serves the cached result instead of running the query again. I wanted to make our query use the query cache instead of having to be run every time. To do that, I just replaced the NOW() in the WHERE condition with today’s date as generated by PHP’s date function. So now the WHERE condition looks like “articles.dateposted > ” . date(’Y-m-d’) . ” - INTERVAL 7 DAY”. That query takes about 100 milliseconds to run the first time, but one millisecond or less to run each subsequent time. Remember: MySQL’s query cache persists beyond requests, so it’s cached for as long as MySQL is running (or until MySQL expires it), not just until the end of PHP’s life at the end of the request.

Was the optimization worth it? Probably not, but it’s always nice to improve the speed of frequently run queries by orders of magnitude.

First things first: We changed hosts. For the past year or so, we’ve been hosted on a dedicated box at Softlayer. I have nothing but good things to say about Softlayer - fair prices (a little higher than Layeredtech, but competitive), good features, responsive support, etc. etc. But the server we purchased was the first dedicated server any of us had ever managed, and crud had started to accumulate and make things very difficult.

To begin with, we had Softlayer set up our box with CPanel, which is sort f the industry standard when it comes to server management-control panels. The problem was that as we started to become more competent, we began changing things manually, and CPanel couldn’t stay in sync and thus was rendered effectively useless. I also had a sneaking suspicion that some of its “helpful” services that run to keep your server maintained were actually slowing us down. I definitely thought that it was time to move to a new
server, one where we could start fresh.

After reading around (the Web Hosting Talk forums are invaluable), I decided Slicehost would be a good place for us. (We also considered Linode.) As I alluded to in my previous post, getting a VPS offered several benefits over a dedicated server. First, Slicehost takes daily and weekly snapshot backups of our server, meaning we could restore to a working server easily if something every happened. Second, we could upgrade the size of our “slice” if we ever experienced a surge in traffic. I suggested it would take “a matter of minutes,” but as neodude pointed out, it actually takes about 10-15 minutes. Regardless, being able to upgrade our server that easily is a very helpful feature.

Additionally, Slicehost’s tutorials for setting up a LAMP server are excellent. We decided to install Ubuntu Gutsy on our slice, and using the magic of apt-get, we had everything we needed set up in just a couple hours (much of that learning how to do some fairly basic things). Most importantly, the server was fresh and entirely configured by us: We could make changes easily and keep everything organized how we wanted to. It is great.

If you have some Linux competency, you should consider setting up your own server. With package managers these days, you don’t need to worry about compiling, just configuring, and even the defaults are generally suitable, so it’s very easy.

There are other fantastic features of Slicehost. Although not actually run by the company, the members of the Slicehost IRC channel have been extremely helpful. Also, Slicehost provides a SSH console in their Web manager that you can use to log in to the server if SSH stops working for some reason. (Like, for example, forgetting to leave your SSH port open in the iptables.)

We’ve made some other tweaks to make our Web site run faster. (Hint: look at the “Server” header we’re sending back.) The goal is to survive a Drudging or something similar. I will have more information in future posts about some more of what we’re doing.