WP-Cache helps my site run smoothly by storing copies of the web pages that are fetched most often from this site, which means that the WordPress system just needs to generate that page once. This has worked fine, except for a mysterious disappearing page problem that happens every once in a while.
A few of you have probably seen it: a visit to a popular page shows just the top-half of the page. I spent a little time debugging this tonight because I saw this problem occur three times with a popular post, which meant that a lot of people were unable to see it when they tried to. Well, no more!
WARNING! Geeky notes follow, so I don't forget what I did.
Occasional Cache Corruption
Every once in a while, someone will send me a nice email telling me that a certain page is coming up "blank", showing just the top-half of the web page with no text. What I usually do in this case is invalidate the cache in the WP-Cache options menu, and this fixes it. Unfortunately, it means all the cached files are also gone, which means the server has to rebuild all the cache files.
I eventually noticed that the problem files could be found by listing the cache contents under the WP-Cache Options panel, seeing which file is unusually small, and then deleting just that file. This tells WP-Cache to rebuild it next time someone requests it. In my case, if I see a posting file that is less than 9K, it's probably screwed up. It appears that the file is truncated, chopped off at a certain point before the rest of WordPress has a chance to populate the page.
After today's issues with my "Procrastinator's Clock" page going under without warning, I decided to poke through the WP-Cache source code to see if I could insert an automatic check, so I wouldn't have to worry about it.
Modifications to WP-Cache
The file wp-cache-phase1.php is that piece of WP-Cache that checks whether a particular URI has been cached already, serving the cached copy if it exists. Around line 35, I inserted the following:
...
foreach ($meta->headers as $header) {
header($header);
}
// DS: start hack
$url = $meta->uri;
$size = @filesize($cache_file);
if ( $size < 9216 ) {
error_log ("WPCache: $size < 9216, expiring $url");
// write problem file
$myFile = "/path/to/writeable/file/in/htdocs/wpcache.log";
$fh = fopen($myFile, 'a') or die("can't open file");
$stringData = file_get_contents($cache_file);
fwrite($fh, "nn##n## Truncated File: ".$meta->uri." ($size) bytesnn");
fwrite($fh, $stringData);
fclose($fh);
// tell WP to recreate cached file
$file_expired = true;
return;
}
// DS: end hack
$log = "<!-- Cached page served by WP-Cache -->n";
if ( !($content_size = @filesize($cache_file)) > 0 || $mtime < @filemtime($cache_file))
...
The code block marked DS: start hack is the new stuff. It grabs the url of the cached file being loaded out of the meta information stored with it and then sees how big the cached copy is. A good page on my site is always bigger than 9K, so if it's LESS than that this means that the cached copy has been screwed up. This error is logged to the PHP Error Log AND the truncated output is written to another file called wpcache.log so I can analyze it later. The hack tells WordPress to re-generate the page by setting the "file expired" flag to true; WP-Cache will then recache it through a different module.
I'm hoping that this ensures that corrupted cache copies don't stick around for hours as they've done in the past. Also, because I'm logging the errors, hopefully I'll be able to figure out what the pattern is that causes this cache corruption to occur.
I got dugg for the first time yesterday, for the Water post of all things, and this was an excellent test of my new Media Temple dedicated virtual (dv) server.
I'm running the very cheapest of (dv) plans ($50/month), which has a "guaranteed" memory allocation of 256MB. It actually can use more, because the (dv) is a virtual server sharing a single machine with others. If you need more memory, and it's available, your server can grab it. Freshly minted, my (dv) was configured to make as much use as possible of this pooled memory, which I suppose encourages people to upgrade to higher-capacity (and more expensive) plans. I can't afford that, so I learned how to modify the MySQL, Apache, and SMTP configuration to run within a 256MB footprint. Then, still seeing esoteric memory allocation failures, I tracked down some significant inefficiencies in my WordPress installation and got rid of them. Just in time too, to handle the unexpected spike in traffic.
It may have been the time of day (2PM), but the peak Digg traffic lasted only a couple hours. Those first couple of hours, though, the (dv) served 2500-2750 pageloads per hour without breaking a sweat, the server load hovering between 0.5 and 0.7 for most of the time. The site remained highly responsive, once I turned off the "KeepAlive" web server option. This option allows a web browser connection to serve more than multiple chunks of data (like all the graphic files on a web page) in one long transaction; ordinarily it's one chunk per transaction. KeepAlive is sort of like being able to monopolize a shoe salesman at a big shoe warehouse, insisting that he bring you a steady stream of shoes for your convenience exclusively. This isn't a problem until the number of pushy customers exceeds the number of salespeople. Then, anyone who's late to the party will wait a looong time to get any service. With 2750 page requests, each with 30 chunks of data and only 30 processes maximum to deal with them, I had to turn off KeepAlive so everyone got served in a timely manner instead of timing out. And yes, I did have a short KeepAliveTimeout set (2 seconds). There is probably some interesting formula to calculate the optimal way to serve the most connections with the least resources, but since I didn't know it I just watched the server and made sure it didn't boil over. When it failed to even get warm, I disabled WP-Cache (remembering to delete the existing cache) to see what kind of increase I'd see. By this time traffic was starting to die off slightly, pulling only 20-40 pageloads per minute, but I saw the load climb to about 1.5 to 2.5. Still not too bad, but I turned the cache back on.
As far as Digg effects go, my experience was relatively mild compared to others. 2750 pageloads/hour is still the record for my site; previously the max I saw was 1600 pageloads/hour, which almost killed the shared host I was on. Of course, the inefficiencies in my WordPress setup (the Mint pepper DLoads, primarily) helped drag the entire server down. I'm starting to keep notes in a new area of the site; if you want a sneak peek, you can read about my experiences with WordPress and shared hosting. I'll be writing up my (dv) experience (and configuration) later.
On a side note, I've been fairly happy with (mt) customer service. They can take a couple days to get back to you via the request system (weekends are especially long), but the quality of support has not been bad. Everyone I've talked with, via email and phone, has been polite and respectful. Of course if you need something done right now or you're experiencing yet another (gs) outage, you probably have a different view of things.
That's it for now!
After I getting linked by several high-profile websites, the increased traffic has forced me to move twice. These notes describe my own experiences with WordPress and its needs. Individual WordPress installations vary in complexity, so your mileage may vary.
An Introduction to Blog Hosting Requirements
I was originally on Pair Networks, a reliable host that I've been with for almost 10 years. My website presence was largely for personal and business use, handling email only. This changed in late 2004, when I started my blog Better Living through New Media. Readership was up to about 100 people a day, through organic search and friends visiting, and Pair's inexpensive Advanced web hosting plan was quite adequate. At $17.95/month, it is considerable more expensive than other popular WordPress hosts like DreamHost, BlueHost, A Small Orange and TextDrive, but it was the host I've been with for years. The WordPress developers have a list of webhosts also that you may want to look at.
When you are starting out, your needs will be pretty basic:
Disk space, measured in megabytes (MB) or gigabytes (GB, which is 1000MB). The WordPress install only takes 3MB, and custom themes may add another megabyte. If you're hosting lots of photos, podcasts, or videos, you'll want more space, but just about any hosting plan will give you enough space. My entire WordPress install is about 500MB currently.
Bandwidth, measured in GB/month or TB/month (terabytes, which is 1000GB). For a site getting started, you'll probably see less than 1GB a month of "normal" use. However, it's the abnormal conditions that you'll have to look out for.
Apache, MySQL, and PHP are the base requirements to run WordPress on a web server. In the case of Pair, the cheapest plan that includes PHP and MySQL is the plan I was using.
The focus of this note is not installing WordPress, but on the traffic levels and server load issues that may drive you to move. For installation help, visit the WordPress Codex.
Getting Started: Low Levels of Traffic
As I've said, you can get started with just about anything. When I started blogging, I installed StatCounter and used this to monitor the amount of traffic I was getting. One nice thing about StatCounter is that is also gives you a nice way of exploring the patterns within the traffic, which gives you an idea of what people are looking at. The three fundamental stats of web traffic are pageviews, unique visitors, and referrals. A pageview is a page loaded with all the accompanying graphics and text. A unique visitor is a person who's been looking at your pages. A referral is where the person "came from", for example another website or perhaps a search engine.
While these stats are all interesting, the one that matters when it comes to choosing a hosting plan is pageviews. When I got started, I had a count of about 10-20 pages a day, which rose to around 100-200 pageviews over the next year. The site remained responsive and snappy...though the pageviews were a lot to me, the server handled this without any problem.
First Sign of Strain: 500 Pageviews A Day
The first sign of trouble was when I hit the 500 pageview-a-day mark, when I noticed the server becoming noticeably slower in delivering webpages. I attributed this to WordPress, which is a dynamic web application. Unlike a regular HTML page, WordPress pages are created "from scratch" every time someone requests one by pulling data out of a database and formatting it on-the-fly. This can become very slow, especially if you've added plugins like Markdown that reprocess all your text.
To deal with the problem, I had two choices: move to a faster server and pay more money, or address the inefficiencies of the WordPress page model. I chose the latter approach, installing the WP-Cache plugin that essentially stores copies of your pages so WordPress doesn't have to create them from scratch. This reduces the strain by a significant factor, and allowed me to stay with Pair for another year.
Time to Move: 1500-2000 Pageviews a Day
I started experiencing more serious problems when I hit the 1500-2000 average pageviews-a-day mark, particularly during peak hours. This is the time of day when the most people are visiting your website at the same time. Your server has to work its hardest, handling many simultaneous requests for web pages with what it has. It's just like rush hour: too many cars on limited road space results in slower traffic flow for everyone. With shared web hosting, there are also other websites sharing your machine, so peak effects can be multiplied.
I started noticing that webpages were taking a long time to come up, and that logging into my admin page to write posts sometimes failed. I also started seeing database connection errors, which indicated that I had exceeded my allotment of bandwidth to the database server. While looking up information about the Pair database servers, I saw that the general consensus was that they are slow compared to other hosting companies. Also, the use of the Mint real-time web traffic statistics package, which had replaced StatCounter for my daily use, was expressly forbidden by Pair's terms of service. They hadn't said anything about it, but the additional database strain added by Mint was probably taking away from overall site performance. It was clearly time to move.
Host Evaluation: Pair shared hosting is great if you're serving lots of static web pages or a small number of dynamic pages through PHP/MySQL.
Picking the New Host
Pair is one of the best web hosts out there, in my experience very responsive and reliable. One caveat: I'm more technical than the average person when it comes to this kind of stuff, familiar enough with server administration that I don't need to ask for a lot of help. I wanted my new hosting provider to have comparable quality of service at an affordable price.
As I looked around, I was struck by many of the complaints and horror stories that were going around practically every host I've mentioned. The only two exceptions were Pair (almost nothing bad said about it, but then again it caters to a more technical crowd) and FutureQuest, which was described as having even better customer support with faster database servers. I did another gut check, which was to google for the phrase "Futurequest sucks". If you try the same thing with other popular hosts, you'll usually see a lot of complaining. Not the case with FutureQuest, so that's who I went with. I moved my files over, restored my database, and I was back in business.
The main issues with FutureQuest were much lower bandwidth and disk space allocations. At the time I moved my main website from Pair, I was on their Webmaster plan for $29.95/month. Bandwidth allocation was 200GB/month, and disk space was 3000MB. My new plan at FutureQuest was $26.95 a month, and included only 20GB of transfer bandwidth and 700MB of disk. At the time, my website was averaging about 15GB of transfer (checkable through the monthly web logs), so I figured I was OK.
The months I spent with FutureQuest were very good. Although I had a few issues with the older version of MySQL they use, once that was cleared up I found the website back to its snappy self. The customer service was everything I had heard, incredibly responsive and proactive. The account control panel, which allows you to do things like set up email accounts and check the status of your service, was also superior to what Pair has in place. I was serving 2500 pageviews a day on average without noticing any degradation in service.
Handling Big Traffic Spikes
The first sign of trouble struck in mid December 2006, when I released a new version of my yearly calendar. It was picked up by the popular site LifeHacker, which immediately drove thousands of people to a particular page on my website during peak hours. The proactive technical staff at FutureQuest noticed immediately that the server was being strained, and promptly emailed me a notification. After 15 minutes, the server was about to completely meltdown, so they disabled my account to keep the websites from the other customers from being dragged down. They emailed me a second time to get back to them as soon as possible.
One problem with having your account disabled is that you have no way of accessing your website or your email. Fortunately I keep my computers running instead of turning them off, so I had a few email reports about incoming traffic that allowed me to see where the unexpected traffic was coming from. I told FutureQuest this, and described the course of action I would take:
- Upload a static version of the webpage, so WordPress wouldn't have to deal with it. Most people following a link will just visit the first page.
- Move the downloadable files associated with the webpage to my old Pair account, which I had maintained because I host other small personal websites there for friends and family.
FutureQuest re-enabled the site within minutes of receiving my email, and I stepped in and made the changes immediately. This allowed the website to stay up with acceptable levels of server load, which is measured in reference to the number 1. Anything less than 1 is a "lightly loaded" server; you can see this number by typing uptime if you're logged into the server with a terminal program. Anything greater than 1 and 2 is "moderately loaded", and if you start seeing numbers greater than that you can expect some sluggishness. In the case of my website, it was causing load spikes of 20-100. After applying the changes, it went back down to a more acceptable 4 to 6: still bad, but not catastrophic. I saw my highest traffic spike ever for the day: 25,000 pageloads.
Typically, the first two days of a spike like this are the highest, and after about a week traffic settles back to normal. The days afterwards you will see elevated levels of traffic from all the secondary linking that occurs from other websites and blogs. All that linking does not go unnoticed by search engines, which raises your site profile in their ranking algorithms and drives increased traffic through search. Because of this extra burst of popularity, I was in danger of exceeding my bandwidth allocation by 5GB. FutureQuest sent me an email based on their predictions, and I upgraded to the next higher-level plan for $35.95/mo. This plan's traffic allocation was 30GB, 10GB more than my old plan.
After all this excitement I thought things would settle back down, but I got linked again a week later, this time to a different part of my website. This time, FutureQuest told me that I needed to either upgrade to a dedicated server ($200 setup, $200/month) or move to avoid these continuing "chronic" problems caused by my website. They also warned me on a separate occasion that my projected bandwidth use was going to be more than double my plan, which would cost me an additional $150 in overage charges if that happened.
I still am very impressed by how their customer service, though in my case it was bad news, was handled so well. I completely understand that being on a shared host with other people entails a certain accountability; I was using far more than my fair share of the server and compromising the level of service for everyone. It was time to move again...$200/month is far too much for me to afford. And $35.95/month for a mere 30GB of transfer is way too low. Compare that to the 100-1000GB allocations you get with other hosting.
Host Evaluation: FutureQuest has phenomenal customer service and technical monitoring for a shared host. However, it's expensive. If you have a smaller website or can afford to pay, it's pretty great. I was sad to leave.
Aside: Website Efficiency
When you get a lot of traffic in a day (and 25K isn't even that high) you really stress the available resources in your service. I had gotten some large spikes before, but nothing on this level. It exposed several inefficiencies in my setup:
The Mint stats package I was using was the source of the server spike. A third-party plugin I had installed was doing some simple download counting in a very inefficient manner, which caused memory use to skyrocket. Removing this plugin brought things down to an acceptable level.
Secondly, increased levels of comment spam were causing high loads on the server as well. I was getting well over a thousand comment spams a day, sometimes as many as 3000, in a single day. Those 3000 spams each have to be filtered by the anti-spam plugins I have running, which themselves burn up server resources. The stats package I'm using does not count these as pageviews, but they do create spikes of use that are problematic.
As a website grows and becomes more feature-laden, your traffic and server load problems increase. If you don't have the time or inclination to learn how to deal with it, it's going to cost money. Either you buy a big dedicated or managed server package ($100-$300/month) or hire someone to handle your server administration for you.
It's important to note that most hosts are not as proactive as FutureQuest. The 15-minute email turnaround time for FutureQuest in handling my website downtime is incredible; you'd have to wait 24 hours to 3 days before getting someone to work with you to resolve your problem. And that bandwidth usage warning email? Most hosts will charge you AFTER you've incurred the overage, which you had no idea was happening, and then you're screwed.
Moderate Levels of Traffic: 3000-5000 pageviews a day
I'm still experiencing increased levels of traffic from those recent surges, and am averaging around 3000-5000 pageviews a day. This is considered by people I've talked to as "significant" website traffic. I was thinking it was time to get away from shared hosting.
When you hit 3000-5000 pageviews a day, you're also at the point where shared hosting isn't enough anymore. Your only option, short of finding a buddy to give you free server space, is to buy dedicated hosting. You get an entire server devoted to your site, but since you're not longer sharing the machine with other people you have to foot the entire bill. Typically, it's between $100-$200 a month, and you're also responsible for keeping it running. There is an even more expensive kind of dedicated hosting called managed hosting, where not only will you get the entire machine to yourself, they'll also run it for you and guarantee its operation.
Since I don't have the hundred bucks a month to spend, I went with Media Temple's dedicated virtual hosting for $50/month. Media Temple is a mainline hosting provider, and provides much more generous disk and bandwidth allocations. MT also offers another hosting plan called the Grid-Server, which takes shared hosting to another level by sharing hundreds of servers with hundreds of websites. Normally, a shared server has a number of customers assigned to it, with each server's resources distinct from each other. With the grid-server technology, the granularity is finer, and the resources from all servers can be put into one common pool. Theoretically, this means you can get fantastic power and value for one low cost. However, this is a new technology and MT is still working out the bugs. I decided to stay with dedicated virtual hosting.
Dedicated virtual hosting is like getting an entire machine to yourself, but in actuality it's a form of shared hosting. The server is actually a software "container" that looks like a stand-alone server, sort of like when a large house is divided into several condominiums. You are guaranteed a certain amount of memory, and if there's any left over you can "burst" to use what's available. Another advantage of dedicated virtual hosting is that you can easily backup your entire server (it's virtual) and you can configure anything you want on it. That's also the downside, because you're also responsible for keeping the thing running. In general this isn't as bad as it sounds, as you can administrate your server using a web-based control panel. However, since I'm using the very cheapest level of dedicated virtual server, I find that there's still some things I need to do to ensure it runs well.
Media Temple sells three levels of dedicated virtual servers, the (dv) Base (which is what I'm using), the (dv) Rage, and the (dv) Extreme. Each server doubles the resources available from the previous level, so the (dv) Rage has twice the memory and disk storage of the (dv) Base. The Base has 256MB of memory, which I know from experience is plenty to run a small server that doesn't have to use graphics. What I didn't know was whether this server would be capable of handling my 3000-5000 pageview-a-day habit.
After a few days of struggling with it, I have it at the point where I'm pretty confident that it'll handle 5000-10,000 pageviews a day without problem. The problemw as this: while the (dv) is set up and ready to go the moment you order it, my particular installation was configured to use as much memory as it could. As I mentioned before, the Base has 256MB of memory, but this is "guaranteed" memory. The virtual server system that is managing all these (dv) virtual servers has a LOT more memory than 256MB, and this is a pool that everyone can draw from. That means if my server needs more than 256MB, and the memory is available, it can get it. If it's NOT, then the memory request fails. The ideal case, from my perspective as someone who wants my server to run well all the time, is to have it all work within my guaranteed memory allocation. From MT's perspective, if the server is telling me I am running out of memory, I am more likely to upgrade to a more expensive server package.
My solution was to spend several days going blind learning how to do basic linux server administration. I configured the mysql database engine to work within 128MB, and limited the number of simultaneous web connections to something reasonable while trimming the number of "modules" loaded by the web server. I also discovered several inefficiencies in the way my WordPress installation was set up relating to poorly-written plugins. I've been monitoring the server live for a few days now, checking the load average as page requests roll in, but these are all subjects for another article.
Another advantage of the (dv) is that you can resell web service. The number of domains you can add to your site, for example, is up to you. You can add up to 30 before you need to buy an additional "Plesk license"; theoretically, I think you can work around this by manually configuring the server. It normally costs money to add new domains to your web account with shared hosting. With 20GB of space, you can afford to bring a few friends on and offset the cost of your hosting, if you're willing to do the administration. The Plesk control panel, which allows you to adminstrate the various functions of your server, can also be configured to show your clients whatever features you think they need. It's a very nice system, and I'll write up my impressions at a later date.
Host Evaluation: Media Temple offers a great value, and they're quite well known in the community. I happen to also get a discount on the service through the 9rules affiliate program, so this makes the service comparable to what I was paying for FutureQuest.
The Next Level
I haven't yet been able to test my server under higher loads. I would guess that's the 10K pageviews-a-day level. If my (dv) holds up to it, then I'm set for a while.
What might change the equation is if I start hosting other websites or add some web applications to the mix. As it is now, I'm running just a single application---WordPress---on this server. If I added a busy BBS or commerce site, then I'll be pushing the limits of the server again, and will be forced to upgrade. At that point, though, I would hope to be making enough money from the Web to justify the cost of a real dedicated server.
Here's how my pageviews vs hosting worked out. Your numbers may be different, based on the number of downloads and images you're hosting on your website.
| PV/DAY |
MAX EST. BW |
PLAN |
| 1-250 |
< 1GB/month |
cheap shared |
| 251-1000 |
5GB/month |
cheap shared |
| 1000-2000 |
10GB/month |
shared |
| 2000-3000 |
30GB/month |
shared |
| 3000-10000 |
100GB/month |
dedicated virtual |
| 10000+ |
100GB+/month |
dedicated? |
So that's my thoughts on the subject. This page will be updated as I learn more. Enjoy!
So here I am on the new server, a dedicated virtual server (dv) from Media Temple. I didn't realize that this (dv) platform is brand new, having launched at the very end of December 2006. Lucky me! My server problems could not have been timed better.
It's only been a few month since I moved to FutureQuest, so the whole How to Move a Working WordPress Installation procedure was relatively fresh in my mind. It worked out a little differently, so I'm documenting this process again.
Geeky notes follow!
The Basic Idea
Since I have a working installation on davidseah.com, I need to do a few things in this order:
- Buy new hosting from Media Temple, keeping the old host active so I can move files.
- Move my email mailboxes over to the new host
- Move my Wordpress files and the MySQL database that powers it
- Move any other non-wordpress services that might exist on the old site.
- Change the official name servers for the davidseah.com domain to use the new ones
What is dedicated virtual hosting?
The dedicated virtual server (dv) from Media Temple is different from the usual shared hosting I was working with. For one thing, you don't share the server with anyone else from your point of view. Technically speaking, you're actually running a simulated dedicated server (that's why it's called "virtual"), on hardware that is shared with other virtual servers. The advantage is that you can make any changes you like to the operating system environment, including having full root access. You also gain the economy that comes from sharing hardware resources, with improved isolation from your neighbors CPU- and memory-hogging hijinx.
On the down side, you need to know something about system administration. The (dv) version 3 package uses an enterprise-level Linux (CentOS) on Virtuozzo, which is controllable to some extent by the Plesk 8.1 control panel. With Plesk, you adminstrate the server and can create clients, domains, and mail users. You can do some limited configuration of common services, but it does assume understanding of how these services work. If words like daemon, mysqld, cron, xinetd, smtp and ssh mean nothing to you, then Plesk might not be all that easy to understand for ya.
The main advantage of Plesk, from my perspective, is that it allows you to manage your domains and hosting clients from within a pretty GUI that works. Plesk also provides a measure of stability on your server because all the software and operating system components have been tested and made to fit together; sort of like having managed hosting without the expense or the expertise. You can purchase additional "snapshots" of your server configuration, which is really really handy if you're the kind of person to mess around with things and need a way to undo the damage. Especially useful if you have a tweaked configuration.
Where Plesk falls short is lower-level configuration of the services it manages. If you want to change the setting of some internal MySQL or PHP variable, you'll have to get root level access to the server (which you can, since it's dedicated to you). Plesk will restart a service (like mail) for you, but that's about it.
Since the server is dedicated, you can install your own software on it. At Media Temple you need to request to have the developer tools installed first, then you can do things like install Ruby on Rails and compile from sources. Note, though, that if you update the "plesk managed" parts of your server, you may not longer be eligble for the automatic updates that MediaTemple will do for you through their Update Option Program.
Getting situated on the new (dv) 3
There was a problem with my order, and I didn't get my welcome emails that described what I was supposed to do. Normally with shared servers, you would receive an email that tells you the basics of how to move your files and how to set up email. I didn't get any of that, so I had to figure it out from scratch.
The good news: You use Plesk to set that all up. The bad news: you're on your own. There is a Plesk User Administration Manual I just found, which is probably worth reading. Until you set up your accounts to allow FTP and ssh into the system, you're sunk. The quick way to do this:
Set up your domain through Plesk. Then select the domain and click the SETUP icon, choose Account Preferences and enter the FTP Login name. This create a user that you can use to FTP into the site. You can also optionally allow this user to SSH in, if you assign a shell using the dropdown menu.
FTP your files using the login name you created. Drop 'em in the httpdocs directory.
Create email mailboxes by clicking back on the domain you created (in my case, davidseah.com) and then clicking MAIL under the Services heading. This is where you can add your email boxes and configure aliases for each one. It's actually pretty nice. I used the exact same names and login credentials for my new mailboxes, so theoretically I won't have to change much in my email program setup.
I'm skipping a lot of strange first-time configuration here...you'll be forced to set up your domain and a default Client. Every domain (like davidseah.com) is tied to a Client (for me, I chose Dave Seah). I can create more domains and clients under my dedicated IP address (up to 30 with the basic license) and run a mini hosting business through Plesk, which is pretty cool.
Moving Your WordPress Files
I've got about 500MB of files on my current host that I got to move, not including the WordPress MySQL database. I could download the files to my computer and re-upload them, but that tends to be slow, so I do a server-to-server FTP transfer. This requires shell access on each host.
Login to both your new server and your old server via SSH. For the purposes of this description, the new server will be called newserver.com and the old one oldserver.com.
On the old server, use the tar command to compress your wordpress folder. Like tar cvzf wordpress.tar.gz wordpress/*, assuming that you're at the same directory level of your wordpress folder.
On the new server, type ftp oldserver.com into the shell and login to your account. Make sure bin is set, then do a get wordpress.tar.gz. Since your hosts have a lot more bandwidth than your crappy home cable connection, this will be way faster.
On the new server, uncompress your archive with tar xvzf wordpress.tar.gz. The entire directory structure will be recreated.
There's actually more than this that you have to do usually, because there are probably other directories you'll want to move, including hidden files like the .htaccess file at the root of your installation. Move 'em all! Make sure you have enough disk space on your old server to create the tarfiles...they can get big, even with the compression.
If all this talk of tar and command-line FTP makes you ill, you could of course just re-upload your wordpress files from your home computer using FTP or DreamWeaver or whatever you're using. My cable modem upload speed is about 40K per second, versus the megabyte-per-second bandwidth when talking server-to-server.
Moving your WordPress Database
The database lives in MySQL, the database engine that stores all of the posts and comments in my blog. This isn't stored as a regular file, so you have to use two command-line tools called mysqldump and mysql.
If you're using WP-CACHE, disable it before doing the following steps.
Shut down your wordpress installation by renaming your wordpress directory or equivalent. You don't want people hitting your database while you're trying to dump out a copy of the data.
Dump the database on oldserver.com into a file called wordpress.sql.gz with the mysqldump command. You can get the values of db_name db_host, db_user, and db_passwd out of your wordpress/wp-config.php file.
mysqldump db_name -hdb_host -udb_user -pdb_passwd -Q --opt > wordpressdb.sql
gzip wordpressdb.sql
FTP the wordpressdb.sql.gz file to newserver.com.
On newserver.com, make sure that you have a database setup with a database user and password. Usually you can find some tool that will do it for you, like PHPMyAdmin or a control panel of some kind.
There's a good chance that the new server will have different db_name, db_user, db_host, etc values, so you'll have to update your wp-config file to use the new values. Do this now!
Assuming you've got the new database set up, it's time to re-import the database. Using the values you just generated when creating the new database and database user, do the following on the new server:
gunzip wordpressdb.sql.gz
mysql db_name -hdb_host -udb_user -pdb_passwd < wordpressdb.sql
If you're very lucky, everything will import cleanly, and you'll get no errors. I got a couple, a "syntax error" that resulted because the MySQL 4.0.x installation on my old server didn't emit quotes properly, as some tables used reserved keywords for their field names (adding the -Q option to mysqldump fixed that). The second error was due to the max_packet_size value being set too small by default on the (dv). It defaults to 1 megabyte, but is usually higher on shared servers. I had to modify the etc/my.cnf file and restart MySQL, which did the trick. You will need root access to edit the configuration file, so make sure you request it immediately when you buy your (dv). It took (mt) 3 days to respond to my request!!!
You might have import problems too if you are downgrading from one version of MySQL to another, as I did the last time I moved. You might want to read the older post for some hints on how to use mysqldump to get around that.
Ok, you've just moved a copy of your wordpress database to the new server! Unfortunately, you've got to do a little surgery on it now, because your new server doesn't have a domain name yet. WordPress stores the domain name in your database, so you'll have to use a database tool like PHPMyAdmin to edit the wp-options table, specifically the siteurl entry, to point to my temporary server address. In my case, it's the numeric IP number of the new server, which is 64.13.223.31. The value of siteurl from my old site is http://davidseah.com/wordpress, so I need to change it to http://64.13.223.31/wordpress so I can test the site.
At this point, I'm ready to test that WordPress has made it over. Visit http://64.13.223.31 in a web browser and cross your fingers. If you get a blank page, that might mean you have to update the WP Cache symbolic link in your wp-content directory (I always forget this). Check your PHP error logs to see what the problem is. You could be missing files from your transfer, or you might need to change permissions for certain folders. My old FutureQuest environment kicked ass, so I had to re-adjust to some of the restrictions in place on the new server.
If everything pops up, yay! You now need to change another option in WordPress temporarily. Login as a wordpress administrator, go to OPTIONS->GENERAL and change the Blog Address to match the numeric IP.
Also, go back and re-enable WP-Cache. You might have to do some additional configuration based on what it complains about.
There's an additional checklist I follow, which is available in part 1. I have just finished running through it, so now I'm ready for the last step.
Do the Nameserver Switch
I control my domain name via a third-party registry, so the last step is to tell the world that the new home of davidseah.com is Media Temple. Media Temple's name servers are responsible for telling the world this now, so I update my domain registration to make them the "name servers of record." Some notes:
Some plugins, like ones that depend on the Flickr API, may not work until the domain name change switches over. At least I think that's what's going on.
It takes 24-48 hours for the entire world to see the switch. In the meantime, email will probably be going to both servers, so be sure to use webmail to check both.
After the new domain servers are stable, I'll switch the WordPress SiteURL options from the numeric IP address back to davidseah.com.
Here goes nothing...see ya on the flip side!
Pulling the switch!!!
UPDATE: I have started writing a guide to configuring the (dv) Base for WordPress to optimize performance. They're quite long, but if you're having problems running out of memory this might be helpful to you.
