Over the Xmas-New Year’s holiday, I decided to move this blog from GoDaddy (feh!) to an Azure virtual machine. There were two reasons. First, I wanted to compare AWS to Azure (Azure is classic MSFT — they are far behind. But they have enough money to catch up and a long history of doing so and then accelerating past the competition.). Second, GoDaddy’s performance stinks — and no matter what you see on your site, when you talk to their support people everything is always running “perfectly” for them.
But I was having massive performance problems from the moment I got the VM running on Ubuntu over on Azure. From just after Xmas until about 10 minutes ago, I just couldn’t get the blog to perform as I knew it should.
So, I went into violent tuning mode. I tuned this parameter and I tuned that startup option. I read every post I could find on tuning php and MySQL. I turned on memcached. I checked and re-checked network definitions. I disabled all the WordPress plugins I use and then enabled them one at at time, running performance checks at each step. All the data pointed to slow MySQL response. So, I tuned buffers. I converted from ISAM to InnoDB. I tuned buffers even more. I even considered adding my own indices to the WordPress database tables. No joy.
After about a five days, I started getting desperate. I increased the instance size of the Azure VM. I even ported the site to EC2 running the very speedy and efficient AWS Linux — a combination I know is ideal for WordPress. Nothing. Performance was for the dogs. Time to first byte on webpagetest.org was still nearly 13 seconds.
It got to the point that it was waking me up in the middle of the night. What was the problem? I’d wake up with an idea (“Ah ha! It must be that freakin’ Azure load balancer!!”), test it all night long (this is a hobby, after all, and I can’t work on it during client time) and then be disappointed when performance didn’t improve in the least.
Nothing — nothing — I did made any difference whatsoever.
I mean, I love this blog even if its appeal is limited to my friends and Google searchers looking for everything from answers to edX finals to AWS PowerShell samples. I’ve been blogging here since mid-2006, when I started bloggin to blow off steam from a bad job I had just left. Since then, it’s become a great learning tool, my online resume and cv as well as a form of self-expression. I wasn’t about to give up on it. Good performance is a point of pride for me — plus I get visitors from all over the world on slower links. I want their experience to be good.
Finally, finally!, I discovered the error by accident. It’s such a simple mistake — and it’s all because I wasn’t careful. I have only myself to blame (of course).
See, WordPress sites are pretty easy to move. I’ve done it dozens of times, for this blog and for clients’ blogs. Basically you SFTP the contents of /wp-content to a new server and use MySQL or phpMyAdmin to export the database to a new server.
In the root of the WordPress folder is a file named wp-config.php in which one names the database, the userid on that database and the name of the server on which WordPress can find its MySQL database. You must change these to reflect the settings on the new server you have just moved the blog to. Nine times out of 10, the name of the server on which the database is located is localhost (or 127.0.0.1). IOW, it’s the same as it was on the old server.
But not for a blog coming from GoDaddy. There, you are given a shared MySQL server hostname string which you use to connect to your database in the define('DB_HOST', ‘hostname here'); parameter of wp-config.php.
Like the village idiot, I had left the settings for GoDaddy. IOW, no matter where I moved the blog, 100% of the MySQL calls were going from Azure (or AWS) to the GoDaddy shared MySQL servers — which are slow to begin with.
Changing to point to my local database solved the problem instantly.
Alex: dumb and dumber.
Leave a Reply