Yesterday, I did the unthinkable. I signed up for a year of GoDaddy hosting on their least expensive (shared) plan. The account is for testing and would hardly qualify as noteworthy, except when viewed through the lens of my background. Let me explain.
A couple years ago I left the fixed hardware world, better known as shared, VPS, and dedicated servers, and set sail for the lush beaches of cloud services. During that time, and continuing today, I worked almost exclusively with Amazon Web Services, Rackspace Public Cloud, and VMware vCloud. It’s been quite a while since I had to contend with a shared host’s control panel or not having been able to control the environment.
So what triggered this confession-causing action?
For me this is more than just a job; I write code and deploy software both during and after working hours for fun while also making a living. I helped start and run the AWP group, for example, because I fell in love with the WP community, not because it’s part of my day job. Inspired in part by Ryan Sullivan’s performance article but taking a different approach on testing user capacity over download speeds, I regularly do a chaos monkey style attempt to try to crash my own site in order to see both the limits of my servers as well as the limits of WordPress, as you can grasp from the graph below.
After building and releasing WP-Chef and writing my article on how WP-Chef now supports Redis Deployment for WordPress I found that I was lacking true comparison information to what most WordPress users are experiencing performance wise and needed to sign up for one of the larger shared services thus GoDaddy was picked. I also have some other non-WordPress LAMP software I wanted to test out and I figured what better place to do that as well. Before I go over that here’s what I saw when signing up.
Handling DNS issues takes too long
I had an idea of what domains I wanted to use for testing purposes. What shocked me was the time lag it took for GoDaddy’s servers to process my DNS changes. Almost every domain I own is purchased through GoDaddy, but immediately added to Route53 which does almost instant change handling. So the minute I add a sub-domain, change an A name or include an MX record, I can immediately test it.
As soon as I signed up for the GoDaddy hosting service it took around 3 hours for the domain to hit. It also took six hours for a sub-domain to get created or deleted. For that matter you’re stuck waiting for whatever automated scripts they’ve built or background process to finally trigger.
This is completely unnecessary and should seriously be attributed to lazy architecture-building than proper DNS server management. Changing DNS doesn’t have to be slow.
I had almost forgotten about Automated Installs
Does anybody remember that? Well of course they do. I might still be one of the few that sees the default install screen with every new WordPress install. For its time it was a great tool but the last time I used a WordPress one-click install was with Media Temple when they first released theirs a few years back. Shortly after switching to AWS I started using bash scripts and eventually discovered Chef which is what I used for WP-Chef in order to build WordPress sites quickly.
What I find interesting is that a lot of hosts still use the off-the-shelf Fantastico or something new called SiteApps (not WordPress) but very few have a customized solution like WP Engine.
I discovered WP Engine’s customized solution while migrating advancedwp.org over to them, as they were gracious enough to give our community group a free hosting account for two years.
Don’t get me wrong, to an end user it must sound great that you can install every open source application known to man on your Shared Server. But if you actually try it, you’ll see just how slow everything goes.
GoDaddy seems to have decided to go the route of creating their own custom solution with a few options that, though seem a bit sludgy, is better than much of what used to exist. Again my only complaint here was speed. I’m used to creating a site in seconds and it takes them forever to have a working WordPress site that I can start playing with.
Site Owners should learn to use more SSH
Right out of the gate I had to go in and turn on SSH and then it was a hassle to get it to work seamlessly. SSH or Secure Shell has been around since the early days of the internet, very simply, it creates a crypto tunnel between your computer and another computer that is very secure and in most cases is able to give you real time interaction with a machine half way across the world. Most secure services, like SFTP for example, borrow from SSH but in the end can’t match the speed and simplicity of it.
When you’re talking about logging into a server to move files around or update software, turn on or off services and a myriad of other options, nothing beats the speed, agility and simplicity of SSH.
Why then should you use it? Well as you’ve probably heard, you shouldn’t be using FTP for anything and if SFTP borrows from SSH in some ways isn’t it just as secure? Though SFTP is pretty secure you miss out on the myriad options given to you through basic SSH. It requires some command line interface (CLI) knowledge but that’s worth trying to learn if you develop for WordPress because it’ll come in handy once you decide to use other tools like WP-CLI and others.
How do you do mundane things such as transfer files over to the server? I use a tool called SSHFS, and it’s a great little tool that mounts all of your servers using the SSH protocol. This treats servers as if they were an external hard drive attached to your machine. The servers then basically become an extension of your own machine including all of the necessary permission commands you may need to run.
The Confession
Aside from using the GoDaddy account for testing WordPress on it, I also have some internal applications that I’m running on my home server that I needed a web IP address for. It’s nothing user-facing that actual people will go to. I’ll be the only person using and running any of these applications.
So I started by replicating a single WordPress site over to GoDaddy, in similar fashion I had one of my domains tied to blitz.io (a hosted performance testing tool) and was all ready to run a comparison test when I realized that they block blitz. I was pissed because here I had gone through the trouble of signing up for a service that I didn’t even want to use and the one tool that I needed to do real comparison testing as it relates to handling user loads was unusable.
So I started building my own called Ruby Blitz, which I’ll be releasing as soon as I’m done testing and will try and publish my results as soon as time permits. My goal here is to get real numbers, numbers of how many real users a site can really handle and obviously I’m not looking to upset anybody so I’ll start off low and work my way up until I feel the server can’t handle it anymore and I’ll stop.
As for those other PHP applications that I’m testing along with WordPress? Well there’s InfiniteWP of course, which many of you guys use, as well as ThinkUp, Zpanel and vTiger. Again these are not applications that anybody will be using or testing but me yet I want to see how they handle on both open and locked down environments.
Conclusion
What shocked me about the whole thing was that you had few options to work with on GoDaddy’s base account—which turned out to be a good thing. Long gone are the endless realms of CPanel options that never actually taught the user anything about server administration and was instead intended to make them think that they were paying for a lot but actually getting very little.
So am I then recommending GoDaddy to you? If you’ve only got $30 a year to spend on a single website and traffic isn’t something you care too much about, then it’s not a bad service for you. If your budget includes a little more than that and you want to have people coming to your website in droves and often (which is why we build sites in the first place) then try Page.ly, WP Engine or DreamPress if your site is WordPress only. If you’re a little more technical and want to get your hands dirty, you can always take WP-Chef out for a spin.
Michael Bastos – Self & School taught C++, Java, PHP, Perl and Ruby Open Source Developer working as a Software Engineer for SPAWAR Research (G2 Software Systems) with a BSCS degree. Started using and developing on WordPress in 2009 and started the AdvancedWP.org community in 2011 which now has over 1,400 members world wide across 3 social networks. Has spoken at over half a dozen or more WordCamps on a range of advanced topics. Message him on twitter @bastosmichael
6 Comments