If you know me, you know that I work on a lot of Drupal sites. You might also know that SliceHost (now a part of RackSpace) is one of the most affordable and simple VPS hosting solutions out there. That said, you might not know that I run several of my own Drupal sites on a single SliceHost 256 slice (256mb ram, that is).
Since I put up my personal blog site using Drupal on a slice, I've noticed that the site, despite being very straightforward as far as Drupal sites go, was not performing very well (3-5 second page loads were common, 400-500ms before initial HTTP response codes). So, I decided to take a closer look to determine what was going on and try to resolve the performance issue.
The first thing I did was to create a duplicate instance of my site on my local Linux development box. I was mildly surprised to find that the local instance of the site was blazingly fast. Understanding that something was causing poor performance in the live version, I continued on and ran an execution profile of a few pages of the site... no glaring performance issues compared to typical Drupal site execution.
That lead me to suspect SliceHost itself. As a virtual server, the system naturally shares physical resources with several other virtual systems. In addition, the CPU and disk IO resources that the VPS has access to are probably highly dependent on the activity of the other virtual servers on the physical server. After watching top on my VPS for a while and reading the observations of others using SliceHost, I came to the conclusion that a good portion of my problem was likely due to the IO delays when the web server was trying to load files or the DB was reading/writing to the disk for whatever reason.
Among the other things I already know are these things: I dont' have the time or inclination to switch to a different VPS vendor, and I don't have the money to pay for more than a 256 slice. So, my solution was to try to work around the issue... using the boost module.
The Boost module is a project to add a static page cache mechanism to Drupal. While Drupal core includes a database-based cache for anonymous users, sometimes performance gains can be realized by the web server loading only a single, flat HTML file instead of executing all sorts of PHP, hitting the database a bunch of times, then outputting the resulting HTML. If the output will be the same each time anyway, a static page cache makes a lot of sense.
Installing boost on Drupal 6 wasn't too bad. Its configuration pages can be a little overwhelming to parse at first, but once I started to gain an understanding of what it was trying to do, things started making a lot more sense. Specifically, boost not only has a static page caching mechanism, but it also features a cron-based crawler that refreshes cached pages as well as pages specifically flagged for cache generating (using boost's block) to keep the static cache nice and preemptively fresh.
Once I deployed boost and made the requisite configuration changes, I re-ran my performance tests (me clicking around with YSlow). Instead of seeing the average page load times around 3-5 seconds, pages (once cached) were loading in less than a second (0.5 - 0.9 seconds specifically). During first-time cache generation, I still see some higher times -- but since I've got my cron-based boost crawler doing the work in the background, most pages should render rather quickly now.