Notes on Switching Servers
Posted on January 14, 2011 in Websites by Jeff Starr
Switching servers & migrating sites can be a HUGE deal (or not), depending on things like:
- Number of sites to transfer
- Size and complexity of sites
- Who is hosting your sites
- Experience
I recently did this, switching from a 3-year run at ASO to my new home at Media Temple. Total of 24 properties, with WordPress running on around 10 sites. Past experience with VPS servers really had me paranoid about running out of memory. A few years ago, Perishable Press alone gobbled up 256MB of RAM at WiredTree, so add another 23 sites on top of that and needless to say I was extremely concerned about the migration from a shared-hosting environment to a (dv) Base account limited to 512MB RAM.
Fortunately, the transfer was a success, and all of my sites (including a few client sites) have been running great ever since. I’ve been keeping a close eye on server memory usage, which averages between 35 - 50% for my entire operation. A much, much better switch than a few years ago, and still plenty of room to grow.
Every little thing..
So how did I do it? I mean, some of my sites (like this one) are 5+ years old, and come with a LOT of baggage. Websites are very much like trees: over time, directory structures grow increasingly complex, with increasing numbers of interconnected files and scripts requiring plenty of resources to thrive. One of my main goals while switching servers was to consolidate and streamline as much as possible. My general migration strategy went something like this:
- Setup new domain in Media Temple account and in Plesk
- In Plesk, setup & configure any extra services or packages
- In Plesk, create the database, mail account, and any subdomains
- Prepare the website to be transferred, upgrade WP, plugins, etc.
- Repair & export database, then import & check
- Clean up files, grep & update any changed paths, etc.
- Check/update htaccess files, database config files, and so on
- Upload entire site (including subdomains) to new server
- Setup any password-protected directories in Plesk
- Check new site using Site Preview (or via hosts file)
- Once everything looks good, switch DNS to (mt) servers
- Keep a close eye on things (like RAM) as traffic rolls in
- Once fully propagated, delete old files, db, etc.
- Have a snack, take a nap
By following this procedure carefully for each site (improvising when needed), I was able to shift my entire online operation from a shared hosting account to a (dv)-Base server with virtually no problems. There was some confusion over subdomain canonicalization, but really that’s about it. Everything else I needed was readily available online (except for one thing, explained in the next section).
Timewise, I think the entire process took about three days. I know that some migrations happen much faster, but I really wanted to take the time to do it right. Some transfers were pretty simple, just static/small sites or whatever. Other sites didn’t make the cut, and others were transferred but soon will be sold (or just deleted). But the main sites required some serious time, focus, and effort. It’s not easy rooting around old files and trying to figure out just what the heck was I thinking when I did that, and then taking the time to re-do it the right way. Tedious, yes, but my sites are in much better condition now than before the switch.
Other notes..
Just to keep it all in one place, here are some of the little things that are too useful to forget.
Keeping an eye on DNS/domain propagation
Throughout the migration process, the following online tools were indispensable:
These tools really helped while evaluating server resources and knowing when DNS propagation was complete.
Previewing the site on the new server
There are at least two ways to preview the site on the new server. The first is to just use Plesk’s built-in Site Preview feature, which makes your pages available at a temporary URL. That worked great for simple/static sites, but for WordPress-powered sites, it is much easier to just modify your computer’s hosts file, as explained here.
Increasing PHP memory on VPS/(dv)
By default, Media Temple’s (dv) server limits each site’s PHP to 32MB. For most sites, this is fine, but when that extra boost of memory is needed, here is the easiest way to make it happen:
- Enable root-access and log in as root via SSH
- Create a
vhost.conffile at/var/www/vhosts/domain.com/conf/ - Add this line to the file:
<Directory /var/www/vhosts/example.com/httpdocs/>php_value memory_limit 64M</Directory> - As root, run this command:
/usr/local/psa/admin/sbin/websrvmng --reconfigure-vhost --vhost-name=example.com - Restart Apache
Of all the different ways to increase PHP memory, this is what actually works on (dv).
Unresolved issues
As mentioned, so far there is only one unresolved issue, and a small one at that. For several of my sites, I’m running Shaun Inman’s Mint Statistics, and everything is working great except for one thing. For some reason, the IP addresses recorded by the Session Tracker extension are shown as 0.0.0.0. About half of the IPs are recorded properly, but the other half are just zeroes.
I’ve scoured Google for a solution, but found nothing that seemed to help. So if you have any ideas, please share them in the comments. Thanks!
Other resources..
Here are other resources that I found most useful during the migration process:
- Optimizing your (dv) server
- Tweaking a Dedicated Virtual Web Server
- How To: Optimize Your Apache Site with Mod Deflate
As well as those already mentioned in the article :)
Quick summary and I’m out..
Transferring my sites to a new server was a great decision. Everything is faster, cleaner, and more secure than ever before. The key to making this happen is finding a good host and taking your time during the migration process. Especially with hosting, time is money, and you get what you pay for.
Exactly what I needed. I may just make use of this President’s day after all! Thanks for sharing. I expected that you’d have to make use of all sorts of nginx and caching related stuff in order to even breath within 512mb, but it’s reassuring to know that it sort of worked out of the box on their servers. I’m sure those things won’t hurt, but it will save having that work upfront. Thanks again, Jeff.
I have been contemplating a similar switch however I have been thinking the cost would be prohibitive. I have 15 sites working pretty well on a shared server (legacy plan at Joyent). When I looked at upgrading it seemed to me that I would need a virtual server for each site which would be very expensive.
It seems that is not the case after reading your post. How many sites are you comfortable with hosting on one server? And if you do not mind, how much are you paying now for your hosting?
Cheers,
Eric
Nice article! I just recently switched over to Media Temple (dv) as well. I’m curious: did you have upload folder permission issues from the get-go? I sure did. Maybe it’s just my lack of experience with advanced server administration, but I had a heck of a time getting WordPress to upload/update without error. I ended up having to set permissions via root access. I wonder if this is a common issue with Media Temple/Wordpress installations or just my lack of experience…
Glad everything went smoothly.
Jeff how do you like Mint? Better than the WP Plugin versions? Statpress etc. Or Google Analytics or StatCounter?
Weird issue with the IP addresses. I don’t use Mint so not sure what it could be. Sounds like a software issue if only half are being recorded.
@Chase - I noticed the same upload folder permission problems with (dv). It is because php is running as the apache user, rather than the domain/FTP user (like on most shared hosting). Apparently you can run PHP as FastCGI and this solves this problem ( http://wiki.mediatemple.net/w/DV:Run_PHP_as_FastCGI_and_resolve_Apache_permission_errors ). I never wanted to go through this change, so instead I just make sure my upload folder is set to 777 permissions and that allows WordPress to write to the directory just fine. Seems like bad practice, but I haven’t found a better way. I also noticed that theme files need to be set to 666 in order to be writable from inside the WordPress admin. I think this is pretty common for VPS setups. All the shared hosting I’ve used is setup differently and doesn’t require these permission changes.
Jeff - I recently got WordPress Multisite working on my (dv). So far so good. I currently have about 15 individual WP installations on my (dv) and a few more on Go Daddy. I plan on rolling them all into this multisite. Looks like it will make my life so much easier. Keeping all these upgraded has become a full time job.
@Chase - Forgot to mention. For doing auto-updates in WordPress, you can add your FTP credentials in wp-config and that will solve that problem. You can find instructions here on digwp ( http://digwp.com/2010/11/ftp-in-wpconfig/ ).
Jeff, like Peter B, the client sites I manage are on a Multisite install.
Consolidating seven upgrades into one reduces maintenance time substantially, although one MS upgrade requires more care than one standalone upgrade.
Donncha’s domain mapping plugin is a godsend.
@Peter B - Thanks for the input. That’s similar to what I did as well. I followed this tutorial to get things running properly:
http://wiki.mediatemple.net/w/DV:Solving_Wordpress_Upload_Folder_Issues
The only issue is that I have to do that with each new wordpress install which is a bit annoying, but I suppose that’s how it goes.
@Chase - But I wonder if giving the apache user group rights is softening the security on the (dv). Just thinking that this is by design for a VPS? Having the apache user no group rights in say shared hosting is less secure than the default VPS setup? Maybe Jeff knows more about this and can chime in. I haven’t done much research on it myself. I’m always hesitant to mess around with too much on the backside with root access. I’ve managed servers in the past, but now with (mt), I’d hate to f something up and then (mt) support come back and say “sorry can’t help you, you knew the risks of root when you enabled.”
@Peter B - You may be 100% correct. I’ll keep digging around. I definitely want to find the “right” way to do it (SOMEONE must know, since I’m sure there are tens of thousands of wordpress sites hosted via Media Temple). That’s why I initially thought it was just inexperience on my part, since everyone seems to be pretty silent about it.
Great post Jeff!
Will help the next time I’m switching servers.
Do you have any content on IPv6?
Thanks everyone for the great feedback!
@Eric: Currently, I’m comfortable hosting as many sites as possible, until the RAM usage begins to top 70% or so. Right now I have 24 sites, some small, some large, all served via 512MB (dv) and the usage stays less than 50%. I think it’s $500/yr for the Base (dv) I’m enjoying now.
@Chase: I’ve had no issues with upload-directories/permissions, but I haven’t really looked too closely at it. Once I get to that point, I’ll report back if there are any issues.
@Skye: Mint is definitely my favorite, but GA is also tops. I just prefer the simplicity and elegance of Mint, and watching people surf around my sites in real-time is SO much fun!
@Peter Bockenhauer: I thought about switching everything over to a MU setup, but many of my WP sites really need to remain independent. I like having each site isolated from the others. It helps to keep things streamlined and organized, updates are usually a breeze, and issues don’t spill over to affect other sites. But MU is awesome and keeps getting better, and I’ll continue to use it for clients and/or when needed.
@Jeff_drumgod: Not sure, really.. How would I find out?
@Jeff: RE: MU/Multisite, yes I will probably have to keep some sites as an individual install. I can think of some sites that I have customized the plugin (and unfortunately have to remember to customize every time I update them). So since multisite uses one set of plugins for all sites, that won’t work so well for sites that use the same plugin.
Being able to setup a new WP install in like 2 minutes is just crazy… definitely worth it for most of the sites we do.
@Peter B, Have found there are one or two plugins that don’t sit well with MS/MU myself. The more complex they are, the less likely they are to have been updated to allow for the merge.
It’s all part of the fun of web development. :)
The only thing that drove me crazy when I switched a single Wordpress site (I know, small migration) was the path of the media folder hidden in the WP settings. I wasn’t able to upload any image untile I figured out. :D
Re IPs showing as 0.0.0.0 : If your [v]server is behind a proxy or load balancer [e.g. Netscaler], misconfigured device doesn’t translate client IP number to the app-server, as a result of which your machine doesn’t know where the package of data is originated from. If this problem persists system-wide [every app on server], then the situation is as described, i.e. it is network configuration related. If it is persisting only for a certain app(s) [mostly those which you installed, those that don’t come pre-installed with the server itself], then it’s application related. In this case, most probably certain network related settings need to be made in your application. There might be a situation where client IP address is translated via some other proxy header, instead of “Remote-Host:”. I think it’s worth checking out…
Check out (mt)’s kb on optimizing your (dv): http://kb.mediatemple.net/questions/771/Optimizing+your+%28dv%29+server
I freed up about 10% memory usage after disabling DNS and SpamAssassin.
Looked into MySQL optimizing. I’ve noticed on (dv) that core and plugin upgrades take longer than they should. The upgrade from 3.0.3 to 3.0.4 took 3mins30secs on (dv) and only about 30secs on my Go Daddy shared hosting. I contacted support and they pointed me to these optimizing docs. As far as I can tell caching was already enabled. Installed MySQLTuner and will look into other changes I can make.
@Shehi: Thank you for sharing that information. I dread the thought of having to hack the app or the extension to fix the 0.0.0.0, but I’m thinking you’re right that it’s an app issue and not a (dv) issue.
@Peter: Yes, that article helped me during the transfer/setup process, but somehow it didn’t turn up while writing the article. The link is now included in the “resources” section of the article. Thanks for the link and for the tips!