Recently when moving website hosts I needed to update the DNS A records to point to the new hosting provider. Global DNS replication can take time and there is a great free tool to perform a DNS lookup against multiple name servers located in different parts of the world. For example, the image below shows that the Google DNS server in Mountain View CA (USA) has a different value to the rest of the DNS servers.
When I tried again an hour later, they were all the same meaning that global replication had finished.
After using Windows Azure to host my WordPress blog for around 6 months, I eventually lost patience with their product offering and support team and starting looking elsewhere. I was receiving ongoing database connection issues and intermediate site outages.
The “This site is currently not available… please try again later” message became very common. This is due to the way Azure manages it’s resource limitations – while other providers will simply throttle your site once you reach a certain level of CPU or RAM usage, Azure actually stops all connections to your website and takes it offline. If you ran a large corporate website, you would enable to scaling options that will allow the instances to grow when there is increased demand however this comes at a financial costs and for me, I couldn’t justify it for a “hobby” blog.
After limiting my WordPress memory usage, I couldn’t understand how I was going over my memory allocation. I opened 2 support cases with Microsoft however after more than 20 emails back and forth, the engineer couldn’t explain what was happening and kept referring me to the pricing page for Azure. Very frustrating, eg “ME: As I have stated 3 times now, I want to understand how the memory usage is calculated – when looking at the monitoring section for the last 7 days, the highest the MemoryWorkingSet gets to is 451.5MB. My WordPress instance is hard limited to 256MB and PHP limited to 128MB of memory. So why am I now constantly being charged for using over 1GB of memory?”. So I gave up on Azure and went over to Amazon.
I figured I would try out their T1 Micro Instances that would cost be around $175 per year (after 12 months of being free). I certainly liked this section of their policy, it was something that Azure didn’t do:
When the Instance Uses Its Allotted Resources – We expect your application to consume only a certain amount of CPU resources in a period of time. If the application consumes more than your instance’s allotted CPU resources, we temporarily limit the instance so it operates at a low CPU level. If your instance continues to use all of its allotted resources, its performance will degrade. We will increase the time that we limit its CPU level, thus increasing the time before the instance is allowed to burst again.
I’m happy for the performance to be degraded, that doesn’t bother me since this is really just a personal blog. Through the AWS Marketplace, I order the WordPress powered by Bitnami, in the Australian data center on a t1.micro EC2 instance.
After a couple of hours of configuring and migrating content, I’m now fully up and running on AWS. So far so good.
Here’s a little about my experience moving the hosting of this WordPress blog to the Azure platform.
I had been using Webcity to host this blog for many years. I would constantly receive warnings about CPU spikes from them because their solution doesn’t scale. This led to my account being suspended a number of times this year and in one week last month there were 2 x 8 hour+ unexplained & un-communicated outages for all hosted websites – this pushed me over the edge to look at other solutions. I liked the idea of more stable infrastructure and the flexibility to scale up and down.
Webcity charged me $150AU per year. Using CPanel, I worked out that my total HTTP traffic per month averaged over the last 6 months is 6GB per month. Based on the Azure pricing calculator (http://azure.microsoft.com/en-us/pricing/calculator/), this means I should actually be saving around $30 per year by using Azure.
To get started, I logged onto https://manage.windowsazure.com and associated my credit card with my existing Windows Live ID (or whatever it is called now). From there, I simply opened the Azure management website, went to Web Sites, Create a Web Site and then From Gallery:
Selected WordPress, then filled in the site details:
On the next page, accept the new Database name or create your own.
After a few minutes, the new website will appear and go into ‘Running’ status. Select the instance and click ‘Browse’:
Fill in your details, these are only temporary as you can change them later. Hit ‘Install WordPress’. After a few minutes there will be a success page.
A basic WordPress site is now up and running, you can visit the URL that you chose at the start – in my case it was http://danovich.azurewebsites.net/ .
The default option is to set up the web hosting plan as ‘Free’, however this doesn’t allow for a custom domain name (danovich.com.au).From the help page: Each plan has a mode associated with it. Different modes expose different sets of features and capabilities. Plans in the Free and Shared modes run on a shared infrastructure with sites managed by other customers. These sites will have strict quotas for resource utilization. Plans in the Basic and Standard modes run on resources that are dedicated to your sites and have fewer restrictions. Also see http://azure.microsoft.com/en-us/pricing/details/websites/To configure this, head back to the Azure management portal, select your website and click on ‘Scale’. In my case I selected Shared, this will be enough for me for now and the beauty of Azure is that I can upgrade to a different plan easily later on if needed.
I originally planned to use a migration tool to move across the site configuration and content however I ran into multiple errors no matter which migration tool I tried:
All-in-One WP Migration
WP Clone by WP Academy
WP Migrate DB
I put this down to the fact that I had a very old and unsupported WordPress theme running plus 6+ years of WordPress customizations. I decided not to use the migration plugin tools and went for using the freshly installed WordPress instance on Azure, picked a new theme, added a handful of useful plugins and then used the native export and import functionality of WordPress to get the old posts across. I then used FTP to copy to uploads directory across.
I remembered that my DNS was hosted with my old web hosting provider, so I upgraded my domain registration provider account to also host by DNS. I entered my handful of A and CNAME records and waited til the next day for replication around the Internet. At the same time, I added an additional A record for migrate.danovich.com.au that pointed to the IP address provided by Azure (screenshot below) and also a CNAME for awverify.migrate.danovich.com.au to point to awverify.migrate.danovich.azurewebsites.net for the purposes of testing before cutting over the remaining DNS records.
After waiting for replication, I went into the Azure management portal –> configuration –> domain names –> manage domains, where I added the new line for migrate.danovich.com.au. I could then use my browser to see that migrate.danovich.com.au was now showing my new website hosted on Azure. The next step was to update my remaining A & CNAME DNS records to point to the IP address or the awverify CNAME that Azure needs for verification.
Once this was done, I could access the website using blog.danovich.com.au or any of the other DNS entries I had added.
Whilst it was very easy to set up a WordPress instance on Azure and relatively easy to import my old content, I’ve had a few issues using Azure – specifically around billing and availability – to the point where I don’t see me continuing to use Azure in the future. I’ll save that for another post…… but overall it was a very easy process to get WordPress up and running on Azure.
After a recent move to Azure, I was doing some performance testing for this blog via gtmetrix.com. My reports were suggesting to ‘leverage browser caching’ and ‘add expires headers’ to improve my performance gradings.
This is usually straight forward to implement; it is simply a few lines added to the sites .htaccess file – either manually or by one of the many WordPress plugins that will update it for you:
Even after this was implemented, I noticed that it wasn’t making any difference to my performance reports – which got me thinking about Azure and that it would be running IIS in the backend and not Apache – and of course IIS doesn’t use the .htaccess file, it uses web.config instead.
After reading a few articles about translating .htaccess content to web.config, I was ready to go. Using FTP, I edited the web.config file in my root directory and added the following lines:
The configuration forces files to be cached on the client side for 28 days and 28 days on the server side except for .php files, which is only 1 hour. I re-ran the performance grading reports and received a much better score!
I can never find the generic Cisco Visio icons when I need them – the product specific ones are well documented on the Cisco support website – however the generic ones that I often need for logical or conceptual diagrams always seem hard to locate. So I’m posting them here so I can find them in future and to help out anyone else who needs them – I don’t believe there are any restrictions on their distribution.
Recently while cleaning up my WordPress database, I noticed that the wp_wps_logs table was over 470MB in size. After a bit of research, I realised this was due to an old plugin that I once used – iThemes Security (formerly Better WP Security). I no longer used this so I needed to get the database size down.
Through cPanel, I opened myPhPAdmin. On the left I navigated to the wp_wps_logs table then clicked on the Operations tab in the top right. Scrolling down to the bottom of the page, there is the option to Empty the table (TRUNCATE). Once I truncated the table, my database size was down to about 20MB!